From dd9cd7c2528826b02aaddbfa91917de04cf13260 Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 4 Aug 2019 18:40:52 +0200 Subject: [PATCH 01/44] revisionato la sezione command-line e corretta parola in what-is --- book/01-introduction/sections/command-line.asc | 18 +++++++++++++++++- book/01-introduction/sections/what-is-git.asc | 2 +- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 0159b8a..64c6535 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,9 +1,25 @@ +//// +=== The Command Line +//// + === La riga di comando +//// +There are a lot of different ways to use Git. +There are the original command-line tools, and there are many graphical user interfaces of varying capabilities. +For this book, we will be using Git on the command line. +For one, the command line is the only place you can run _all_ Git commands -- most of the GUIs implement only a partial subset of Git functionality for simplicity. +If you know how to run the command-line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true. +Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available. + +So we will expect you to know how to open Terminal in macOS or Command Prompt or PowerShell in Windows. +If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book. +//// + Ci sono molti modi diversi di usare Git. C'è la linea di comando originale e ci sono molte interfacce grafiche ciascuna con le proprie capacità. Per questo manuale useremo la riga di comando di Git. -Principalmente perché la riga di comando è l'unico posto dove puoi eseguire *tutti* i comandi di Git. Molte interfacce grafiche, per semplificare, implementano solo una parte delle funzionalità di Git. +Principalmente perché la riga di comando è l'unico posto dove puoi eseguire_tutti_ i comandi di Git -- molte interfacce grafiche, per semplificare, implementano solo una parte delle funzionalità di Git. Se sai cosa fare sulla riga di comando, molto probabilmente saprai usare anche l'interfaccia grafica, ma non è necessariamente vero l'opposto. Inoltre l'interfaccia grafica è qualosa che rispecchia un gusto personale, mentre _tutti_ gli utenti avranno installata e disponibile la riga di comando. diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 837b802..d4989fe 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -263,5 +263,5 @@ In <>, you'll learn more about Se una particolare versione di un file è nella directory git, viene considerata già committata (_committed_). Se il file è stato modificato, ma è stato aggiunto all'area di staging, è _in stage_. -E se è stato modificato da quando è stata estratto, ma non è _in stage_, è _modificato_. +E se è stato modificato da quando è stato estratto, ma non è _in stage_, è _modificato_. In <>, imparerai di più su questi stati e come trarne vantaggio o saltare la parte di staging. From 7fd8fa89abe8639767839a2dfdbed96aa3bb5782 Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 4 Aug 2019 20:10:01 +0200 Subject: [PATCH 02/44] revisionato command-line e iniziato traduzione di installing --- .../01-introduction/sections/command-line.asc | 2 +- book/01-introduction/sections/installing.asc | 171 ++++++++++++++---- 2 files changed, 138 insertions(+), 35 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 64c6535..a1e28a8 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -2,7 +2,7 @@ === The Command Line //// -=== La riga di comando +=== La Riga di Comando //// There are a lot of different ways to use Git. diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 914f37a..c5f825d 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -1,87 +1,190 @@ +//// === Installing Git +//// +=== Installare Git + +//// Before you start using Git, you have to make it available on your computer. Even if it's already installed, it's probably a good idea to update to the latest version. You can either install it as a package or via another installer, or download the source code and compile it yourself. [NOTE] ==== -This book was written using Git version *2.0.0*. Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine. +This book was written using Git version *2.8.0*. +Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. +Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine. ==== +//// + +Prima di iniziare ad utilizzare Git, devi renderlo disponibile sul tuo computer. +Anche se è già installato, probabilmente è una buona idea aggiornarlo all'ultima versione. +Puoi installarlo sia come un pacchetto o tramite altro installatore, sia scaricando il codice sorgente e compilandolo autonomamente. +[NOTE] +==== +Questo libro è stato scritto utilizzando Git versione *2.8.0*. +Tuttavia la maggior parte dei comandi utilizzati dovrebbe funzionare anche nelle versioni vecchie di Git, alcuni di questi potrebbero o meno agire in modo leggermente diverso se utilizzi una versione precedente. +Poiché Git è davvero eccezionale nel mantenere la retro-compatibilità, tutte le versioni dopo la 2.0 dovrebbero funzionare bene. +==== + +//// ==== Installing on Linux +//// + +==== Installare su Linux +//// (((Linux, installing))) -If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. -If you're on Fedora for example, you can use yum: +If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the package management tool that comes with your distribution. +If you're on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use `dnf`: + +[source,console] +---- +$ sudo dnf install git-all +---- + +If you're on a Debian-based distribution, such as Ubuntu, try `apt`: + +[source,console] +---- +$ sudo apt install git-all +---- + +For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[]. +//// + + +Se vuoi installare gli strumenti base di Git su Linux, tramite una installazione da binario, generalmente puoi farlo con lo strumento base di amministrazione dei pacchetti della tua distribuzione. +Se usi Fedora (o qualsiasi distribuzione strettamente correlata su base RPM, come RHEL o CentOS), puoi usare `dnf`: + +[source,console] +---- +$ sudo dnf install git-all +---- + +Se usi una distribuzione basata su Debian, come Ubuntu, prova `apt`: + +[source,console] +---- +$ sudo apt install git-all +---- - $ yum install git +Per maggiori opzioni, le istruzioni per l'installazione su molte distribuzioni Unix differenti sono sul sito web di Git all'indirizzo https://git-scm.com/download/linux[]. -If you're on a Debian-based distribution like Ubuntu, try apt-get: - $ apt-get install git -For more options, there are instructions for installing on several different Unix flavors on the Git website, at http://git-scm.com/download/linux[]. -==== Installing on Mac -(((Mac, installing))) + + +==== Installing on macOS + +(((macOS, installing))) There are several ways to install Git on a Mac. The easiest is probably to install the Xcode Command Line Tools.(((Xcode))) On Mavericks (10.9) or above you can do this simply by trying to run 'git' from the Terminal the very first time. + +[source,console] +---- +$ git --version +---- + If you don't have it installed already, it will prompt you to install it. If you want a more up to date version, you can also install it via a binary installer. -An OSX Git installer is maintained and available for download at the Git website, at http://git-scm.com/download/mac[]. +A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[]. -.Git OS X Installer. -image::images/git-osx-installer.png[Git OS X installer.] +.Git macOS Installer. +image::images/git-osx-installer.png[Git macOS installer.] -You can also install it as part of the GitHub for Mac install. +You can also install it as part of the GitHub for macOS install. Their GUI Git tool has an option to install command line tools as well. -You can download that tool from the GitHub for Mac website, at http://mac.github.com[]. +You can download that tool from the GitHub for macOS website, at https://desktop.github.com[]. ==== Installing on Windows There are also a few ways to install Git on Windows.(((Windows, installing))) The most official build is available for download on the Git website. -Just go to http://git-scm.com/download/win[] and the download will start automatically. -Note that this is a project called Git for Windows (also called msysGit), which is separate from Git itself; for more information on it, go to http://msysgit.github.io/[]. +Just go to https://git-scm.com/download/win[] and the download will start automatically. +Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[]. + +To get an automated installation you can use the https://chocolatey.org/packages/git[Git Chocolatey package]. +Note that the Chocolatey package is community maintained. -Another easy way to get Git installed is by installing GitHub for Windows. +Another easy way to get Git installed is by installing GitHub Desktop. The installer includes a command line version of Git as well as the GUI. -It also works well with Powershell, and sets up solid credential caching and sane CRLF settings.(((Powershell)))(((CRLF)))(((credential caching))) +It also works well with PowerShell, and sets up solid credential caching and sane CRLF settings.(((PowerShell)))(((CRLF)))(((credential caching))) We'll learn more about those things a little later, but suffice it to say they're things you want. -You can download this from the GitHub for Windows website, at http://windows.github.com[]. - +You can download this from the https://desktop.github.com[GitHub Desktop website]. ==== Installing from Source Some people may instead find it useful to install Git from source, because you'll get the most recent version. The binary installers tend to be a bit behind, though as Git has matured in recent years, this has made less of a difference. -If you do want to install Git from source, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. -For example, if you're on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: +If you do want to install Git from source, you need to have the following libraries that Git depends on: autotools, curl, zlib, openssl, expat, and libiconv. +For example, if you're on a system that has `dnf` (such as Fedora) or `apt-get` (such as a Debian-based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: + +[source,console] +---- +$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \ + openssl-devel perl-devel zlib-devel +$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ + gettext libz-dev libssl-dev +---- + +In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required (Note: users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package): + +[source,console] +---- +$ sudo dnf install asciidoc xmlto docbook2X +$ sudo apt-get install asciidoc xmlto docbook2x +---- + +If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package: + +[source,console] +---- +$ sudo apt-get install install-info +---- + +If you're using a RPM-based distribution (Fedora/RHEL/RHEL-derivatives), you also need the `getopt` package (which is already installed on a Debian-based distro): + +[source,console] +---- +$ sudo dnf install getopt +$ sudo apt-get install getopt +---- + +Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this - $ yum install curl-devel expat-devel gettext-devel \ - openssl-devel zlib-devel +[source,console] +---- +$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi +---- - $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ - libz-dev libssl-dev +due to binary name differences. When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. -You can get it via the Kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub web site, at https://github.com/git/git/releases[]. +You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[]. It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. Then, compile and install: - $ tar -zxf git-1.9.1.tar.gz - $ cd git-1.9.1 - $ make configure - $ ./configure --prefix=/usr - $ make all doc info - $ sudo make install install-doc install-html install-info +[source,console] +---- +$ tar -zxf git-2.0.0.tar.gz +$ cd git-2.0.0 +$ make configure +$ ./configure --prefix=/usr +$ make all doc info +$ sudo make install install-doc install-html install-info +---- After this is done, you can also get Git via Git itself for updates: - $ git clone git://git.kernel.org/pub/scm/git/git.git +[source,console] +---- +$ git clone git://git.kernel.org/pub/scm/git/git.git +---- From bf967ad5752d145fc4e91aa288a43d86a8bfa6a6 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 6 Aug 2019 19:53:03 +0200 Subject: [PATCH 03/44] in installing tradotto installare_su_mac e installare_su_windows --- book/01-introduction/sections/installing.asc | 50 ++++++++++++++++++-- 1 file changed, 45 insertions(+), 5 deletions(-) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index c5f825d..60154a3 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -55,6 +55,7 @@ For more options, there are instructions for installing on several different Uni //// +(((Linux, installing))) Se vuoi installare gli strumenti base di Git su Linux, tramite una installazione da binario, generalmente puoi farlo con lo strumento base di amministrazione dei pacchetti della tua distribuzione. Se usi Fedora (o qualsiasi distribuzione strettamente correlata su base RPM, come RHEL o CentOS), puoi usare `dnf`: @@ -73,11 +74,7 @@ $ sudo apt install git-all Per maggiori opzioni, le istruzioni per l'installazione su molte distribuzioni Unix differenti sono sul sito web di Git all'indirizzo https://git-scm.com/download/linux[]. - - - - - +//// ==== Installing on macOS (((macOS, installing))) @@ -101,7 +98,33 @@ image::images/git-osx-installer.png[Git macOS installer.] You can also install it as part of the GitHub for macOS install. Their GUI Git tool has an option to install command line tools as well. You can download that tool from the GitHub for macOS website, at https://desktop.github.com[]. +//// + +==== Installare su macOS + +(((macOS, installing))) +Ci sono molti modi di installare Git su un Mac. +Il più semplice è probabilmente quello di installare l'Xcode Command Line Tools.(((Xcode))) +Su Mavericks (10.9), o versioni seguenti, puoi farlo semplicemente provando a far funzionare 'git' da terminale la prima volta in assoluto. + +[source,console] +---- +$ git --version +---- + +Se non è già installato, ti verrà richiesto di installarlo. + +Se desideri una versione più aggiornata, puoi anche installarlo tramite un installatore binario. +Un installatore di Git per macOS è mantenuto e reso disponibile per il download sul sito web di Git, all'indirizzo https://git-scm.com/download/mac[]. + +.Installatore di Git per macOS. +image::images/git-osx-installer.png[Installatore di Git per macOS.] + +Puoi anche installarlo come parte dell'installazione di GitHub per macOS. +La loro interfaccia grafica di Git ha una opzione per installare anche gli strumenti da riga di comando. +Puoi scaricare questo strumento dal sito web di GitHub per macOS, all'indirizzo https://desktop.github.com[]. +//// ==== Installing on Windows There are also a few ways to install Git on Windows.(((Windows, installing))) @@ -117,6 +140,23 @@ The installer includes a command line version of Git as well as the GUI. It also works well with PowerShell, and sets up solid credential caching and sane CRLF settings.(((PowerShell)))(((CRLF)))(((credential caching))) We'll learn more about those things a little later, but suffice it to say they're things you want. You can download this from the https://desktop.github.com[GitHub Desktop website]. +//// + +==== Installare su Windows + +C'é anche qualche modo di installare Git su Windows.(((Windows, installing))) +La versione più ufficiale é disponibile per il download sul sito web di Git. +E' sufficiente visitare https://git-scm.com/download/win[] ed il download partirà automaticamente. +Si noti che questo é un progetto chiamato Git for Windows, che è separato da Git stesso; per maggiori informazioni sul progetto si veda https://gitforwindows.org[]. + +Per ottenere una installazione automatica si può utilizzare https://chocolatey.org/packages/git[Git Chocolatey package]. +Si noti che il package Chocolatey é mantenuto dalla comunità. + +Un altro modo semplice per ottenere Git installato è quello di installare il Desktop di GitHub. +L'installatore include la versione a linea di comando così come la GUI. +Questa versione funziona bene anche con PowerShell, imposta un consistente sistema di memorizzazione delle credenziali in cache e una configurazione CRLF sensata.(((PowerShell)))(((CRLF)))(((credential caching))) +Su queste cose impareremo di più un po' più tardi, ma basti dire che sono le cose che servono. +Si può scaricare questa versione dal https://desktop.github.com[Sito web GitHub Desktop]. ==== Installing from Source From 8829dad168571f71a618968d0786a6435c70c2fe Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 6 Aug 2019 22:54:06 +0200 Subject: [PATCH 04/44] ultimata traduzione di installing --- book/01-introduction/sections/installing.asc | 43 +++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 60154a3..025423b 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -158,6 +158,7 @@ Questa versione funziona bene anche con PowerShell, imposta un consistente siste Su queste cose impareremo di più un po' più tardi, ma basti dire che sono le cose che servono. Si può scaricare questa versione dal https://desktop.github.com[Sito web GitHub Desktop]. +//// ==== Installing from Source Some people may instead find it useful to install Git from source, because you'll get the most recent version. @@ -165,6 +166,15 @@ The binary installers tend to be a bit behind, though as Git has matured in rece If you do want to install Git from source, you need to have the following libraries that Git depends on: autotools, curl, zlib, openssl, expat, and libiconv. For example, if you're on a system that has `dnf` (such as Fedora) or `apt-get` (such as a Debian-based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: +//// + +==== Installare da Sorgenti + +Alcune persone potrebbero invece trovare utile installare Git dai sorgenti perché si avrà la versione più recente. +Anche se Git è maturato negli anni recenti, gli installatori binari tendono ad essere solo un po' indietro e questo ha fatto meno differenza. + +Se vuoi installare Git dai sorgenti, hai bisogno delle librerie da cui dipende che sono: autotools, curl, zlib, openssl, expat e libiconv. +Per esempio, se sei su un sistema che usa `dnf` (come Fedora), o `apt-get` (come nei sistemi Debian), puoi usare uno dei seguenti comandi per installare le dipendenze minime per compilare ed installare i binari di Git: [source,console] ---- @@ -173,8 +183,11 @@ $ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \ $ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-dev ---- - +//// In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required (Note: users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package): +//// + +Al fine di essere in grado di aggiungere la documentazione in vari formati (doc, html, info) sono richieste queste ulteriori dipendenze (Nota: gli utenti di RHEL e derivate, come CentOS e Scientific Linux, dovranno https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[abilitare il repository EPEL] per scaricare il pacchetto `docbook2X`): [source,console] ---- @@ -182,14 +195,22 @@ $ sudo dnf install asciidoc xmlto docbook2X $ sudo apt-get install asciidoc xmlto docbook2x ---- +//// If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package: +//// + +Se stai utilizzando una distribuzione basata su Debian (Debian/Ubuntu/derivate di Ubuntu) ti serve anche il pacchetto `install-info`: [source,console] ---- $ sudo apt-get install install-info ---- +//// If you're using a RPM-based distribution (Fedora/RHEL/RHEL-derivatives), you also need the `getopt` package (which is already installed on a Debian-based distro): +//// + +Se stai utilizzando una distribuzione basata su RPM (Fedora/RHEL/derivate di RHEL) ti serve anche il pacchetto `getopt` (che è già installato in una distro a base Debian): [source,console] ---- @@ -197,20 +218,36 @@ $ sudo dnf install getopt $ sudo apt-get install getopt ---- +//// Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this +//// + +In aggiunta, se stai utilizzando Fedora/RHEL/derivate di RHEL hai bisogno di dare questo comando [source,console] ---- $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi ---- +//// due to binary name differences. +//// + +a causa delle differenze nel nome del binario. +//// When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[]. It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. Then, compile and install: +//// + +Quando avrai tutte le dipendenze necessarie, puoi proseguire ed andare a recuperare l'archivio compresso (_tarball_) dell'ultima versione numerata da svariati posti. +Puoi ottenerlo tramite il sito kernel.org all'indirizzo https://www.kernel.org/pub/software/scm/git[] o dal mirror sul sito web di GitHub all'indirizzo https://github.com/git/git/releases[]. +In genere è un po 'più chiaro quale sia l'ultima versione nella pagina GitHub, ma la pagina kernel.org ha anche le firme di rilascio se si desidera verificare il download. + +Poi, compilalo ed installalo: [source,console] ---- @@ -222,7 +259,11 @@ $ make all doc info $ sudo make install install-doc install-html install-info ---- +//// After this is done, you can also get Git via Git itself for updates: +//// + +Dopo aver fatto questo, puoi scaricare gli aggiornamenti di Git con Git stesso : [source,console] ---- From e792ed4db0b69ede3fe0538e940b5cb46d161761 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 6 Aug 2019 23:44:41 +0200 Subject: [PATCH 05/44] iniziata traduzione di firs --- .../sections/first-time-setup.asc | 70 ++++++++++++++++--- 1 file changed, 61 insertions(+), 9 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 7eb9c91..74ee9c9 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,27 +1,59 @@ -[[r_first_time]] +[[_first_time]] +//// === First-Time Git Setup +//// +=== Prima Configurazione di Git + +//// Now that you have Git on your system, you'll want to do a few things to customize your Git environment. You should have to do these things only once on any given computer; they'll stick around between upgrades. You can also change them at any time by running through the commands again. +//// + +Ora che hai Git sul tuo sistema vorrai fare un paio di cose per personalizzare l'ambiente di Git. +Devi farle solo una volta: rimarrano invariate anche dopo un aggiornamento. Puoi comunque cambiarle in ogni momento, rieseguendo i comandi. +//// Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.(((git commands, config))) These variables can be stored in three different places: +//// + +Assieme a Git c'é uno strumento che si chiama `git config` che ti permetterà d'impostare e conoscere le variabili di configurazione che controllano ogni aspetto di come appare Git e come opera.(((git commands, config))) +Queste variabili possono essere salvate in tre posti differenti: +//// 1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. -2. `~/.gitconfig` or `~/.config/git/config` file: Specific to your user. - You can make Git read and write to this file specifically by passing the `--global` option. +//// + +1. il file `/etc/gitconfig`: Contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. + + +2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user. + You can make Git read and write to this file specifically by passing the `--global` option, and this affects _all_ of the repositories you work with on your system. 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. + You can force Git to read from and write to this file with the `--local` option, but that is in fact the default. + (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +If you are using version 2.x or later of Git for Windows, there is also a system-level config file at +`C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer. +This config file can only be changed by `git config -f ` as an admin. + +You can view all of your settings and where they are coming from using: + +[source,console] +---- +$ git config --list --show-origin +---- ==== Your Identity -The first thing you should do when you install Git is to set your user name and e-mail address. +The first thing you should do when you install Git is to set your user name and email address. This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: [source,console] @@ -31,14 +63,16 @@ $ git config --global user.email johndoe@example.com ---- Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. -If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you're in that project. +If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project. Many of the GUI tools will help you do this when you first run them. +[[_editor]] ==== Your Editor Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. -If not configured, Git uses your system's default editor, which is generally Vim. +If not configured, Git uses your system's default editor. + If you want to use a different text editor, such as Emacs, you can do the following: [source,console] @@ -46,15 +80,32 @@ If you want to use a different text editor, such as Emacs, you can do the follow $ git config --global core.editor emacs ---- +On a Windows system, if you want to use a different text editor, you must specify the full path to its executable file. +This can be different depending on how your editor is packaged. + +In the case of Notepad++, a popular programming editor, you are likely to want to use the 32-bit version, since at the time of writing the 64-bit version doesn't support all plug-ins. +If you are on a 32-bit Windows system, or you have a 64-bit editor on a 64-bit system, you'll type something like this: + +[source,console] +---- +$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" +---- + +[NOTE] +==== +Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix-based systems like Linux and macOS or a Windows system. +If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in <>. +==== + [WARNING] ==== -Vim and Emacs are popular text editors often used by developers on Unix based systems like Linux and Mac. If you are not familiar with either of these editors or are on a Windows system, you may need to search for instructions for how to set up your favorite editor with Git. -If you don't set an editor like this and you don't know what Vim or Emacs are, you will likely get into a really confusing state when they are launched. +You may find, if you don't setup your editor like this, you get into a really confusing state when Git attempts to launch it. +An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit. ==== ==== Checking Your Settings -If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: +If you want to check your configuration settings, you can use the `git config --list` command to list all the settings Git can find at that point: [source,console] ---- @@ -78,3 +129,4 @@ You can also check what Git thinks a specific key's value is by typing `git conf $ git config user.name John Doe ---- + From afa0898003c8b1c7348d5f291a148c74b071b4f2 Mon Sep 17 00:00:00 2001 From: Fedro Date: Mon, 12 Aug 2019 16:38:41 +0200 Subject: [PATCH 06/44] inseriti altri 3 paragrafi in first --- .../sections/first-time-setup.asc | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 74ee9c9..acf240d 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -27,14 +27,27 @@ Queste variabili possono essere salvate in tre posti differenti: If you pass the option `--system` to `git config`, it reads and writes from this file specifically. //// -1. il file `/etc/gitconfig`: Contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. - +1. il file `/etc/gitconfig`: contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. +//// 2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user. You can make Git read and write to this file specifically by passing the `--global` option, and this affects _all_ of the repositories you work with on your system. +//// + +2. il file `~/.gitconfig` oppure `~/.config/git/config`: Valori specifici personali per te, come utente. +Puoi far leggere e scrivere a Git questo file passando l'opzione `--global` e questo ha effetto su tutti gli archivi con cui lavori sul tuo sistema. + +//// 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. You can force Git to read from and write to this file with the `--local` option, but that is in fact the default. (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) +//// + +3. file `config` nella directory di Git (cioè `.git/config`) di qualsiasi repository che si stia usando. È Specifico di quel singolo repository. +Si può forzare Git a leggere e scrivere su questo file con l'opzione `--local`, ma questo in realtà é il valore predefinito. +(Prevedibilmente é necessario trovarsi da qualche parte in un repository di Git affinchè questa opzione funzioni correttamente). +Ogni livello sovrascrive i valori del precedente, così che i valori in `.git/config` vincono su quelli in `/etc/gitconfig`. + Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. From f10db1a245b7ee322b86d795d014b9428b384392 Mon Sep 17 00:00:00 2001 From: Fedro Date: Mon, 12 Aug 2019 22:15:28 +0200 Subject: [PATCH 07/44] compleata la sezione first-time-setup --- .../sections/first-time-setup.asc | 85 ++++++++++++++++++- 1 file changed, 84 insertions(+), 1 deletion(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index acf240d..0cdd1c5 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -48,26 +48,50 @@ Si può forzare Git a leggere e scrivere su questo file con l'opzione `--local`, (Prevedibilmente é necessario trovarsi da qualche parte in un repository di Git affinchè questa opzione funzioni correttamente). Ogni livello sovrascrive i valori del precedente, così che i valori in `.git/config` vincono su quelli in `/etc/gitconfig`. - +//// Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +//// +//// On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +//// + +Su Windows Git cerca il file `.gitconfig` nella directory `$HOME` (`C:\Users\$USER` per la maggior parte delle persone). +Controlla comunque anche `/etc/gitconfig`, sebbene sia relativo alla root di MSys, che è dove hai deciso di installare Git in Windows quando si lancia l'installazione. + +//// If you are using version 2.x or later of Git for Windows, there is also a system-level config file at `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer. This config file can only be changed by `git config -f ` as an admin. +//// + +Se stai utilizzando la versione 2.x, o successive, di Git for Windows, c'é anche un file di configurazione a livello di sistema in `C:\Documents and Settings\All Users\Application Data\Git\config` su Windows XP, e in `C:\ProgramData\Git\config` su Windows Vista e seguenti. +//// You can view all of your settings and where they are coming from using: +//// + +Puoi vedere tutte le tue impostazioni e da dove derivano utilizzando: [source,console] ---- $ git config --list --show-origin ---- +//// ==== Your Identity +//// +==== La tua Identità + +//// The first thing you should do when you install Git is to set your user name and email address. This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: +//// + +La prima cosa che occorrerebbe fare quando installi Git è impostare il tuo nome utente e il tuo indirizzo e-mail. +Questo è importante perché ogni commit di Git usa queste informazioni che vengono immutabilmente incapsulate nelle registrazioni che inizi a creare: [source,console] ---- @@ -75,50 +99,101 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- +//// Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project. +//// + +Come detto, con l'opzione `--global` dovrai farlo solo una volta, dopo di che Git userà sempre queste informazioni per qualsiasi operazione fatta sul sistema. +Se vuoi sovrascriverle con un nome o una email diversi per progetti specifici potrai eseguire il comando senza l'opzione `--global`stando in uno di quei progetti. +//// Many of the GUI tools will help you do this when you first run them. +//// + +Molti degli strumenti GUI ti aiuteranno a farlo quando li eseguirai la prima volta. [[_editor]] +//// ==== Your Editor +//// +==== Il tuo Editor +//// Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. If not configured, Git uses your system's default editor. If you want to use a different text editor, such as Emacs, you can do the following: +//// + +Ora che hai configurato la tua identità, puoi configurare il tuo editor di testo predefinito, che verrà usato quando Git avrà bisogno che tu scriva un messaggio. + +Se non é configurato, Git usa l'editor di testo predefinito del sistema. + +Se vuoi usarne uno diverso, come Emacs, potrai eseguire: [source,console] ---- $ git config --global core.editor emacs ---- +//// On a Windows system, if you want to use a different text editor, you must specify the full path to its executable file. This can be different depending on how your editor is packaged. In the case of Notepad++, a popular programming editor, you are likely to want to use the 32-bit version, since at the time of writing the 64-bit version doesn't support all plug-ins. If you are on a 32-bit Windows system, or you have a 64-bit editor on a 64-bit system, you'll type something like this: +//// + +Su un sistema Windows, se vuoi utilizzare un editor di testo differente, devi specificare il percorso completo del suo eseguibile. +Questo percorso può essere differente a seconda di come è pacchettizzato il tuo editor. + +Nel caso di Notepad++, un popolare editor per programmatori, probabilmente vorrai utilizzare la versione a 32 bit, dato che nel momento in cui scrivo la versione a 64 bit non supporta tutti i plug-in. +Se sei su un sistema Windows a 32 bit o se hai un editor a 64 bit su un sistema a 64 bit, digiterai qualcosa che assomiglia a questo: [source,console] ---- $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" ---- +//// [NOTE] ==== Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix-based systems like Linux and macOS or a Windows system. If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in <>. ==== +//// +[NOTE] +==== +Vim, Emacs e Notepad++ sono popolari editor di testo spesso utilizzati dagli sviluppatori sui sistemi a base Unix come Linux e macOS o su sistemi Windows. +Se stai utilizzando un altro editor, o una versione a 32 bit, troverai istruzioni specifiche su come configurare il tuo editor preferito con Git in <>. +==== + +//// [WARNING] ==== You may find, if you don't setup your editor like this, you get into a really confusing state when Git attempts to launch it. An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit. ==== +//// +[WARNING] +==== +Se non si imposta il proprio editor in questo modo, quando Git tenta di avviarlo si potrebbe scoprire di trovarsi in uno stato estremamente confuso. +Su un sistema Windows ad esempio si potrebbe arrivare al blocco imprevisto di Git al momento dell'inizio delle modifiche del testo. +==== +//// ==== Checking Your Settings +//// + +==== Controlla le Tue Impostazioni +//// If you want to check your configuration settings, you can use the `git config --list` command to list all the settings Git can find at that point: +//// + +Per controllare le tue impostazioni puoi usare il comando `git config --list` che elenca tutte le impostazioni attuali di Git: [source,console] ---- @@ -132,10 +207,18 @@ color.diff=auto ... ---- +//// You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees. You can also check what Git thinks a specific key's value is by typing `git config `:(((git commands, config))) +//// + +Potresti vedere più volte la stessa chiave perché Git legge la stessa chiave da file differenti (`/etc/gitconfig` e `~/.gitconfig`, per esempio). +In questo caso, Git usa l'ultimo valore per ogni chiave unica che trova. + +Puoi anche controllare quale sia il valore di una chiave specifica digitando `git config {key}`:(((git commands, config))) + [source,console] ---- From a0c2d4b014e738e154b32f31d16d641d90e18cba Mon Sep 17 00:00:00 2001 From: Fedro Date: Mon, 12 Aug 2019 23:21:47 +0200 Subject: [PATCH 08/44] ultimo paragrafo di first e revisione di help --- .../sections/first-time-setup.asc | 15 +++++ book/01-introduction/sections/help.asc | 63 ++++++++++++++++--- 2 files changed, 71 insertions(+), 7 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 0cdd1c5..12bd7ed 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -226,3 +226,18 @@ $ git config user.name John Doe ---- +[NOTE] +==== +//// +Since Git might read the same configuration variable value from more than one file, it's possible that you have an unexpected value for one of these values and you don't know why. +In cases like that, you can query Git as to the _origin_ for that value, and it will tell you which configuration file had the final say in setting that value: +//// +Poiché Git potrebbe leggere lo stesso valore di variabile di configurazione da più di un file, é possibile che si abbia un dato inaspettato per uno di questi valori e di non sapere il perché. +In casi come questo puoi interrogare Git sull'_origine_ di tale valore e lui ti dirà quale file di configurazione abbia l'ultima parola nell'impostazione di questo dato: + +[source,console] +---- +$ git config --show-origin rerere.autoUpdate +file:/home/johndoe/.gitconfig false +---- +==== diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 1d286fd..937d44f 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -1,7 +1,15 @@ -[[r_git_help]] -=== Chiedere aiuto +[[_git_help]] +//// +=== Getting Help +//// -Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per visualizzare la pagina di aiuto (pagina man) di ciascun comando di Git, direttamente dal manuale. +=== Ottenere Aiuto + +//// +If you ever need help while using Git, there are three equivalent ways to get the comprehensive manual page (manpage) help for any of the Git commands: +//// + +Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi equivalenti per vedere le pagine complete del manuale (manpage) per ogni comando di Git: [source,console] ---- @@ -10,13 +18,54 @@ $ git --help $ man git- ---- -Puoi, per esempio, leggere la pagina man del comando config eseguendo(((git commands, help))) +//// +For example, you can get the manpage help for the `git config` command by running(((git commands, help))) +//// + +Per esempio, puoi consultare la pagina del manuale per il comando `git config` digitando(((git commands, help))) [source,console] ---- $ git help config ---- -Questi comandi sono belli perché puoi accedervi da qualsiasi posto, anche se non sei collegato -Se le pagine del manuale e questo libro non fossero necessari e hai bisogno di un aiuto di una persona, puoi provare nei canali irc `#git` o `#github` del server Freenode IRC (irc.freenode.net). -In questi canali ci sono normalmente centinaia di persone esperte di Git che sono spesso disponibili ad aiutare gli altri.(((IRC))) +//// +These commands are nice because you can access them anywhere, even offline. +If the manpages and this book aren't enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server, which can be found at https://freenode.net[]. +These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC))) + +In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise ``help'' output with the `-h` or `--help` options, as in: +//// + +Questi comandi sono belli perché puoi accedervi dappertutto, anche quando sei offline. +Se il manuale e questo libro non fossero sufficienti e avessi bisogno dell'aiuto di una persona, puoi provare i canali `#git` o `#github` sul server IRC di Freenode, che si può trovare su https://freenode.net[]. +Questi canali sono frequentati regolarmente da centinaia di persone che conoscono molto bene Git e spesso sono disponibili per dare una mano.(((IRC))) + +//// +In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise ``help'' output with the `-h` or `--help` options, as in: +//// +In aggiunta, se non ti serve l'aiuto esteso dalla manpage, ma solo un veloce ripasso delle opzioni disponibili per un comando Git, puoi richiedere il più conciso output di ``help'' con le opzioni `-h` o `--help`, come in: + +[source,console] +---- +$ git add -h +usage: git add [] [--] ... + + -n, --dry-run dry run + -v, --verbose be verbose + + -i, --interactive interactive picking + -p, --patch select hunks interactively + -e, --edit edit current diff and apply + -f, --force allow adding otherwise ignored files + -u, --update update tracked files + --renormalize renormalize EOL of tracked files (implies -u) + -N, --intent-to-add record only the fact that the path will be added later + -A, --all add changes from all tracked and untracked files + --ignore-removal ignore paths removed in the working tree (same as --no-all) + --refresh don't add, only refresh the index + --ignore-errors just skip files which cannot be added because of errors + --ignore-missing check if - even missing - files are ignored in dry run + --chmod (+|-)x override the executable bit of the listed files +---- + From 79943c917bbc331d5fa82fc3d6820684f2c84a96 Mon Sep 17 00:00:00 2001 From: Fedro Date: Mon, 12 Aug 2019 23:42:40 +0200 Subject: [PATCH 09/44] modifica per eliminare errori di compilazione nella lista numerata di first --- book/01-introduction/sections/first-time-setup.asc | 5 ----- 1 file changed, 5 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 12bd7ed..2ced71d 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -26,23 +26,18 @@ Queste variabili possono essere salvate in tre posti differenti: 1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. //// - 1. il file `/etc/gitconfig`: contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. - //// 2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user. You can make Git read and write to this file specifically by passing the `--global` option, and this affects _all_ of the repositories you work with on your system. //// - 2. il file `~/.gitconfig` oppure `~/.config/git/config`: Valori specifici personali per te, come utente. Puoi far leggere e scrivere a Git questo file passando l'opzione `--global` e questo ha effetto su tutti gli archivi con cui lavori sul tuo sistema. - //// 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. You can force Git to read from and write to this file with the `--local` option, but that is in fact the default. (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) //// - 3. file `config` nella directory di Git (cioè `.git/config`) di qualsiasi repository che si stia usando. È Specifico di quel singolo repository. Si può forzare Git a leggere e scrivere su questo file con l'opzione `--local`, ma questo in realtà é il valore predefinito. (Prevedibilmente é necessario trovarsi da qualche parte in un repository di Git affinchè questa opzione funzioni correttamente). From a3c450fe90a2b5c0f622345e4e903dae2451cb83 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 13 Aug 2019 00:02:24 +0200 Subject: [PATCH 10/44] ulteriore fase di eliminazione errori di compilazione --- C-git-commands.asc | 4 ++-- .../sections/first-time-setup.asc | 19 ++++++++++--------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index 6d7fa89..3671c35 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -17,7 +17,7 @@ Git has a default way of doing hundreds of things. For a lot of these things, yo The `git config` command has been used in nearly every chapter of the book. -In <> we used it to specify our name, email address and editor preference before we even got started using Git. +In <> we used it to specify our name, email address and editor preference before we even got started using Git. In <> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time. @@ -33,7 +33,7 @@ Finally, basically the entirety of <> is dedi The `git help` command is used to show you all the documentation shipped with Git about any command. While we're giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run `git help `. -We introduced the `git help` command in <> and showed you how to use it to find more information about the `git shell` in <>. +We introduced the `git help` command in <> and showed you how to use it to find more information about the `git shell` in <>. === Getting and Creating Projects diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 2ced71d..982b28d 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -25,28 +25,29 @@ Queste variabili possono essere salvate in tre posti differenti: //// 1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. -//// -1. il file `/etc/gitconfig`: contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. -//// 2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user. You can make Git read and write to this file specifically by passing the `--global` option, and this affects _all_ of the repositories you work with on your system. -//// -2. il file `~/.gitconfig` oppure `~/.config/git/config`: Valori specifici personali per te, come utente. -Puoi far leggere e scrivere a Git questo file passando l'opzione `--global` e questo ha effetto su tutti gli archivi con cui lavori sul tuo sistema. -//// 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. You can force Git to read from and write to this file with the `--local` option, but that is in fact the default. (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) //// + +1. il file `/etc/gitconfig`: contiene i valori per ogni utente sul sistema e per tutti i loro repository. + Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. + (Dato che questo è un file di configurazione di sistema, avresti bisogno di privilegi di amministratore o superutente per farci dei cambiamenti). +2. il file `~/.gitconfig` oppure `~/.config/git/config`: Valori specifici personali per te, come utente. + Puoi far leggere e scrivere a Git questo file passando l'opzione `--global` e questo ha effetto su tutti gli archivi con cui lavori sul tuo sistema. 3. file `config` nella directory di Git (cioè `.git/config`) di qualsiasi repository che si stia usando. È Specifico di quel singolo repository. -Si può forzare Git a leggere e scrivere su questo file con l'opzione `--local`, ma questo in realtà é il valore predefinito. + Si può forzare Git a leggere e scrivere su questo file con l'opzione `--local`, ma questo in realtà é il valore predefinito. (Prevedibilmente é necessario trovarsi da qualche parte in un repository di Git affinchè questa opzione funzioni correttamente). -Ogni livello sovrascrive i valori del precedente, così che i valori in `.git/config` vincono su quelli in `/etc/gitconfig`. //// Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. //// +Ogni livello sovrascrive i valori del precedente, così che i valori in `.git/config` vincono su quelli in `/etc/gitconfig`. + + //// On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. From 6613e8b80162c454b150b143b9209001469dfaf6 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 13 Aug 2019 00:17:00 +0200 Subject: [PATCH 11/44] aggiornameto percentuali di traduzione --- status.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/status.json b/status.json index 1c1d249..02ad870 100644 --- a/status.json +++ b/status.json @@ -6,12 +6,12 @@ "01-introduction": { "1-introduction.asc": 100, "sections/about-version-control.asc": 100, - "sections/basics.asc": 30, "sections/command-line.asc": 100, - "sections/first-time-setup.asc": 0, + "sections/first-time-setup.asc": 100, "sections/help.asc": 100, "sections/history.asc": 100, - "sections/installing.asc": 0 + "sections/installing.asc": 100, + "sections/what-is-git.asc": 100 }, "02-git-basics": { "1-git-basics.asc": 0, From cf8092c761c095f1a02e236e9b1ad91c9e4abbbe Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 14 Aug 2019 13:58:34 +0200 Subject: [PATCH 12/44] tradotto il file ch02 --- ch02-git-basics-chapter.asc | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index 08db254..b8da0a1 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -1,10 +1,21 @@ [[ch02-git-basics-chapter]] +//// == Git Basics +//// +== Basi di Git + +//// If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you'll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. We'll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. +//// + +Se puoi leggere un solo capitolo per imparare Git, leggi questo. +Questo capitolo illustra tutti i comandi base di cui hai bisogno per la stragrande maggioranza delle cose che farai con Git. +Alla fine del capitolo sarai in grado di configurare e creare un repository, iniziare e interrompere il tracciamento dei file e mettere in stage e committare le modifiche. +Vedremo come impostare Git per ignorare certi file o pattern, come annullare velocemente e facilmente gli errori, come navigare la cronologia del tuo progetto e vedere le modifiche tra le varie commit e come fare il push ed il pull da repository remoti. include::book/02-git-basics/sections/getting-a-repository.asc[] @@ -20,7 +31,17 @@ include::book/02-git-basics/sections/tagging.asc[] include::book/02-git-basics/sections/aliases.asc[] +//// === Summary +//// + +=== Sommario +//// At this point, you can do all the basic local Git operations -- creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. Next, we'll cover Git's killer feature: its branching model. +//// + +A questo punto, sei in grado di eseguire tutte le operazioni di base di Git in locale: creare o clonare un repository, fare delle modifiche, mettere nello `stage` e inviare queste modifiche, vedere la cronologia delle modifiche fatte al repository. +Nel prossimo capitolo, vedremo la caratteristica vincente di Git: il suo modello di ramificazione. + From cc7999247bb214d1d3f4019430b54589aec64960 Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 14 Aug 2019 14:11:21 +0200 Subject: [PATCH 13/44] iniziata sezione getting --- book/02-git-basics/sections/getting-a-repository.asc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 6b5d2b1..501f453 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,5 +1,9 @@ -[[r_getting_a_repo]] +[[_getting_a_repo]] +//// === Getting a Git Repository +//// + +=== Repository Git You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. From 000c81410585a78871bbffeebdf5c19e60803b2e Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 15 Aug 2019 18:51:55 +0200 Subject: [PATCH 14/44] sostituita la sezione getting del ch02 con l'originale inglese --- .../sections/getting-a-repository.asc | 55 +++++++++++++------ 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 501f453..ea7a21c 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,24 +1,42 @@ [[_getting_a_repo]] -//// === Getting a Git Repository -//// -=== Repository Git +You typically obtain a Git repository in one of two ways: -You can get a Git project using two main approaches. -The first takes an existing project or directory and imports it into Git. -The second clones an existing Git repository from another server. +1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or +2. You can _clone_ an existing Git repository from elsewhere. + +In either case, you end up with a Git repository on your local machine, ready for work. ==== Initializing a Repository in an Existing Directory -If you're starting to track an existing project in Git, you need to go to the project's directory and type +If you have a project directory that is currently not under version control and you want to start controlling it with Git, you first need to go to that project's directory. +If you've never done this, it looks a little different depending on which system you're running: + +for Linux: +[source,console] +---- +$ cd /home/user/my_project +---- +for macOS: +[source,console] +---- +$ cd /Users/user/my_project +---- +for Windows: +[source,console] +---- +$ cd /c/user/my_project +---- + +and type: [source,console] ---- $ git init ---- -This creates a new subdirectory named `.git` that contains all of your necessary repository files – a Git repository skeleton. +This creates a new subdirectory named `.git` that contains all of your necessary repository files -- a Git repository skeleton. At this point, nothing in your project is tracked yet. (See <> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) @@ -35,26 +53,27 @@ $ git commit -m 'initial project version' We'll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit. -[[r_git_cloning]] +[[_git_cloning]] ==== Cloning an Existing Repository -If you want to get a copy of an existing Git repository – for example, a project you'd like to contribute to – the command you need is `git clone`. +If you want to get a copy of an existing Git repository -- for example, a project you'd like to contribute to -- the command you need is `git clone`. If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". -This is an important distinction – instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. +This is an important distinction -- instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down by default when you run `git clone`. -In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there – see <> for more details). +In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there -- see <> for more details). -You clone a repository with `git clone [url]`.(((git commands, clone))) -For example, if you want to clone the Git linkable library called libgit2, you can do so like this: +You clone a repository with `git clone `.(((git commands, clone))) +For example, if you want to clone the Git linkable library called `libgit2`, you can do so like this: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -That creates a directory named ``libgit2'', initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. -If you go into the new `libgit2` directory, you'll see the project files in there, ready to be worked on or used. -If you want to clone the repository into a directory named something other than ``libgit2'', you can specify that as the next command-line option: +That creates a directory named `libgit2`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. +If you go into the new `libgit2` directory that was just created, you'll see the project files in there, ready to be worked on or used. + +If you want to clone the repository into a directory named something other than `libgit2`, you can specify the new directory name as an additional argument: [source,console] ---- @@ -65,4 +84,4 @@ That command does the same thing as the previous one, but the target directory i Git has a number of different transfer protocols you can use. The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. -<> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +<> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. From aa860b5beb2439e88a7b69339bf6e4e0f8ce1c14 Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 15 Aug 2019 20:34:40 +0200 Subject: [PATCH 15/44] avanzamento nella traduzione di getting --- .../sections/getting-a-repository.asc | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index ea7a21c..6919d52 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,47 +1,90 @@ [[_getting_a_repo]] +//// === Getting a Git Repository +//// +=== Ottenere un Repository Git + +//// You typically obtain a Git repository in one of two ways: 1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or 2. You can _clone_ an existing Git repository from elsewhere. In either case, you end up with a Git repository on your local machine, ready for work. +//// + +Solitamente è possibile ottenere un repository Git in uno di questi due modi: + +1. Puoi prendere una directory locale, che al momento non è sotto controllo di versione, e trasformarla in un repository Git, oppure +2. Puoi _clonare_ da un qualsiasi altro posto un repository Git esistente. + +In entrambi i casi ci si ritrova con un repository Git sul proprio computer locale, pronto per il lavoro. +//// ==== Initializing a Repository in an Existing Directory +//// +==== Creare un repository in una directory preesistente + +//// If you have a project directory that is currently not under version control and you want to start controlling it with Git, you first need to go to that project's directory. If you've never done this, it looks a little different depending on which system you're running: for Linux: +//// + +Se hai la directory di un progetto che al momento non é sotto controllo di versione e voui iniziare a controllarla con Git, per prima cosa devi andare nella directory di questo progetto. +Se non l'hai mai fatto, ti sembrerà un po' diverso a seconda di quale sistema tu stia utilizzando: + +per Linux: [source,console] ---- $ cd /home/user/my_project ---- +//// for macOS: +//// +per macOS: [source,console] ---- $ cd /Users/user/my_project ---- +//// for Windows: +//// +per Windows: [source,console] ---- $ cd /c/user/my_project ---- +//// and type: +//// + +e digiti: [source,console] ---- $ git init ---- +//// This creates a new subdirectory named `.git` that contains all of your necessary repository files -- a Git repository skeleton. At this point, nothing in your project is tracked yet. (See <> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`: +//// + +Questo creerà una nuova sottodirectory chiamata `.git` che conterrà tutti i file necessari per il tuo repository -- una struttura del repository Git. +A questo punto non è ancora stato tracciato niente del tuo progetto. +(Vedi il <> per sapere precisamente quali file sono contenuti nella directory `.git` che hai appena creato.) + +Se vuoi iniziare a tracciare i file esistenti (a differenza di una directory vuota), dovresti iniziare a monitorare questi file con una commit iniziale. +Lo puoi fare con pochi `git add`, che specificano quali file vuoi tracciare, seguiti da un `git commit`: [source,console] ---- @@ -50,12 +93,23 @@ $ git add LICENSE $ git commit -m 'initial project version' ---- +//// We'll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit. +//// + +Tra un minuto vedremo cosa fanno questi comandi. +A questo punto hai un repository Git con dei file tracciati e una commit iniziale. [[_git_cloning]] +//// ==== Cloning an Existing Repository +//// + +==== Clonare un Repository Esistente + +//// If you want to get a copy of an existing Git repository -- for example, a project you'd like to contribute to -- the command you need is `git clone`. If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". This is an important distinction -- instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. @@ -64,6 +118,15 @@ In fact, if your server disk gets corrupted, you can often use nearly any of the You clone a repository with `git clone `.(((git commands, clone))) For example, if you want to clone the Git linkable library called `libgit2`, you can do so like this: +//// + +Se vuoi copiare un repository Git esistente -- per esempio, un progetto a cui vuoi contribuire -- il comando di cui hai bisogno è `git clone`. +Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è "clone" e non "checkout". +Questa è una distinzione importante -- invece di ottenere una semplice copia di lavoro, Git riceve sostanzialmente una copia completa di tutti i dati che sono sul server. +Quando esegui `git clone` vengono scaricate tutte le versioni di ciascun file della cronologia del progetto. Infatti, se si danneggiasse il disco del tuo server, potresti usare qualsiasi clone di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (potresti perdere alcuni `hooks` lato-server, ma tutte le versioni dei dati saranno presenti: vedi il *Capitolo 4* per maggiori dettagli). + +Cloni un repository con `git clone [url]`. Per esempio, se vuoi clonare la libreria Ruby Git chiamata Grit, puoi farlo così: + [source,console] ---- From 3e5f475c2d51d76477221505c9820733b93f45e0 Mon Sep 17 00:00:00 2001 From: Fedro Date: Fri, 16 Aug 2019 09:37:36 +0200 Subject: [PATCH 16/44] ultimata la sezione getting --- .../sections/getting-a-repository.asc | 33 ++++++++++++++----- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 6919d52..3d64dbe 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -2,7 +2,6 @@ //// === Getting a Git Repository //// - === Ottenere un Repository Git //// @@ -24,7 +23,6 @@ In entrambi i casi ci si ritrova con un repository Git sul proprio computer loca //// ==== Initializing a Repository in an Existing Directory //// - ==== Creare un repository in una directory preesistente //// @@ -34,7 +32,7 @@ If you've never done this, it looks a little different depending on which system for Linux: //// -Se hai la directory di un progetto che al momento non é sotto controllo di versione e voui iniziare a controllarla con Git, per prima cosa devi andare nella directory di questo progetto. +Se hai la directory di un progetto che al momento non é sotto controllo di versione e vuoi iniziare a controllarla con Git, per prima cosa devi andare nella directory di questo progetto. Se non l'hai mai fatto, ti sembrerà un po' diverso a seconda di quale sistema tu stia utilizzando: per Linux: @@ -63,7 +61,7 @@ $ cd /c/user/my_project and type: //// -e digiti: +e digitare: [source,console] ---- @@ -105,7 +103,6 @@ A questo punto hai un repository Git con dei file tracciati e una commit inizial //// ==== Cloning an Existing Repository //// - ==== Clonare un Repository Esistente @@ -123,16 +120,18 @@ For example, if you want to clone the Git linkable library called `libgit2`, you Se vuoi copiare un repository Git esistente -- per esempio, un progetto a cui vuoi contribuire -- il comando di cui hai bisogno è `git clone`. Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è "clone" e non "checkout". Questa è una distinzione importante -- invece di ottenere una semplice copia di lavoro, Git riceve sostanzialmente una copia completa di tutti i dati che sono sul server. -Quando esegui `git clone` vengono scaricate tutte le versioni di ciascun file della cronologia del progetto. Infatti, se si danneggiasse il disco del tuo server, potresti usare qualsiasi clone di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (potresti perdere alcuni `hooks` lato-server, ma tutte le versioni dei dati saranno presenti: vedi il *Capitolo 4* per maggiori dettagli). - -Cloni un repository con `git clone [url]`. Per esempio, se vuoi clonare la libreria Ruby Git chiamata Grit, puoi farlo così: +Quando esegui `git clone` vengono automaticamente scaricate tutte le versioni di ciascun file della cronologia del progetto. +Infatti, se si danneggiasse il disco del tuo server, spesso potresti usare quasi ogni clone di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (potresti perdere alcuni `hooks` lato-server, ma tutte le versioni dei dati saranno presenti: vedi il <> per maggiori dettagli). +Cloni un repository con `git clone [url]`.(((git commands, clone))) +Per esempio, se vuoi clonare la libreria dinamica Git chiamata `libgit2`, puoi farlo così: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- +//// That creates a directory named `libgit2`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new `libgit2` directory that was just created, you'll see the project files in there, ready to be worked on or used. @@ -144,7 +143,25 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit ---- That command does the same thing as the previous one, but the target directory is called `mylibgit`. +//// + +Questo comando crea un directory `libgit2`, dentro di questa inizializza una directory `.git`, scarica tutti i dati del repository e fa il checkout dell'ultima versione per poterci lavorare su. +Se vai nella nuova directory `libgit2`, vedrai i file del progetto, pronti per essere modificati o usati. +Se vuoi clonare il repository in una directory con un nome diverso da `libgit2`, puoi specificare il nome della nuova directory come ulteriore argomento sulla riga di comando: + +[source,console] +---- +$ git clone https://github.com/libgit2/libgit2 mylibgit +---- +Questo comando fa la stessa cosa del precedente, ma la directory di destinazione è chiamata `mylibgit`. + +//// Git has a number of different transfer protocols you can use. The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. <> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +//// + +Git può usare differenti protocolli di trasferimento. +L'esempio precedente usa il protocollo `https://`, ma puoi anche vedere `git://` o `user@server:/path/to/repo.git`, che usa il protocollo di trasferimento SSH. +Il <> introdurrà tutte le opzioni che un server può rendere disponibili per l'accesso al repository Git e i pro e i contro di ciascuna. From 4393c1e98077a6f77c5f61dd720dae773a5d1a33 Mon Sep 17 00:00:00 2001 From: Fedro Date: Fri, 16 Aug 2019 12:34:27 +0200 Subject: [PATCH 17/44] sostituita la sezione recording con l'originale inglese --- .../sections/recording-changes.asc | 176 +++++++++++------- 1 file changed, 106 insertions(+), 70 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 3167796..e48751f 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,20 +1,22 @@ === Recording Changes to the Repository -You have a bona fide Git repository and a checkout or working copy of the files for that project. -You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. +Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. -Remember that each file in your working directory can be in one of two states: tracked or untracked. +Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. +In short, tracked files are files that Git knows about. + +Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. +When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. As you edit files, Git sees them as modified, because you've changed them since your last commit. -You stage these modified files and then commit all your staged changes, and the cycle repeats. +As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. .The lifecycle of the status of your files. image::images/lifecycle.png[The lifecycle of the status of your files.] -[[r_checking_status]] +[[_checking_status]] ==== Checking the Status of Your Files The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) @@ -24,16 +26,17 @@ If you run this command directly after a clone, you should see something like th ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- -This means you have a clean working directory – in other words, there are no tracked and modified files. +This means you have a clean working directory; in other words, none of your tracked files are modified. Git also doesn't see any untracked files, or they would be listed here. Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. For now, that branch is always ``master'', which is the default; you won't worry about it here. -<> will go over branches and references in detail. +<> will go over branches and references in detail. -Let's say you add a new file to your project, a simple README file. +Let's say you add a new file to your project, a simple `README` file. If the file didn't exist before, and you run `git status`, you see your untracked file like so: [source,console] @@ -41,6 +44,7 @@ If the file didn't exist before, and you run `git status`, you see your untracke $ echo 'My Project' > README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) @@ -49,28 +53,29 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -You can see that your new README file is untracked, because it's under the ``Untracked files'' heading in your status output. +You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including README, so let's start tracking the file. +You do want to start including `README`, so let's start tracking the file. -[[r_tracking_files]] +[[_tracking_files]] ==== Tracking New Files In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the README file, you can run this: +To begin tracking the `README` file, you can run this: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your README file is now tracked and staged to be committed: +If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -79,19 +84,20 @@ Changes to be committed: ---- You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add (files)` – that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) +If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. +You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. ==== Staging Modified Files Let's change a file that was already tracked. -If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this: +If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -105,15 +111,18 @@ Changes not staged for commit: ---- -The ``CONTRIBUTING.md'' file appears under a section named ``Changed but not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again: +The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. +To stage it, you run the `git add` command. +`git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. +It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) +Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: [source,console] ---- $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -132,6 +141,7 @@ However, let's run `git status` one more time: $ vim CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -158,6 +168,7 @@ If you modify a file after you run `git add`, you have to run `git add` again to $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -167,7 +178,9 @@ Changes to be committed: ==== Short Status -While the `git status` output is pretty comprehensive, it's also quite wordy. Git also has a short status flag so you can see your changes in a more compact way. If you run `git status -s` or `git status --short` you get a far more simplified output from the command. +While the `git status` output is pretty comprehensive, it's also quite wordy. +Git also has a short status flag so you can see your changes in a more compact way. +If you run `git status -s` or `git status --short` you get a far more simplified output from the command: [source,console] ---- @@ -179,9 +192,12 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified. So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. +There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. +So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. +The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. -[[r_ignoring]] +[[_ignoring]] ==== Ignoring Files Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. @@ -196,43 +212,44 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code. -The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. +The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. +The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. The rules for the patterns you can put in the `.gitignore` file are as follows: * Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work. +* Standard glob patterns work, and will be applied recursively throughout the entire working tree. +* You can start patterns with a forward slash (`/`) to avoid recursivity. * You can end patterns with a forward slash (`/`) to specify a directory. * You can negate a pattern by starting it with an exclamation point (`!`). Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9). +An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. -Here is another example .gitignore file: +Here is another example `.gitignore` file: [source] ---- -# no .a files +# ignore all .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a -# only ignore the root TODO file, not subdir/TODO +# only ignore the TODO file in the current directory, not subdir/TODO /TODO -# ignore all files in the build/ directory +# ignore all files in any directory named build build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt -# ignore all .txt files in the doc/ directory -doc/**/*.txt +# ignore all .pdf files in the doc/ directory and any of its subdirectories +doc/**/*.pdf ---- [TIP] @@ -240,13 +257,23 @@ doc/**/*.txt GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. ==== -[[r_git_diff_staged]] +[NOTE] +==== +In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. +However, it is also possible to have additional `.gitignore` files in subdirectories. +The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. +(The Linux kernel source repository has 206 `.gitignore` files.) + +It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. +==== + +[[_git_diff_staged]] ==== Viewing Your Staged and Unstaged Changes -If the `git status` command is too vague for you – you want to know exactly what you changed, not just which files were changed – you can use the `git diff` command.(((git commands, diff))) +If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed – the patch, as it were. +Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed -- the patch, as it were. Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. If you run your `git status` command, you once again see something like this: @@ -255,10 +282,11 @@ If you run your `git status` command, you once again see something like this: ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) - new file: README + modified: README Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -281,9 +309,9 @@ index 8ebb991..643e24f 100644 if we have to read the whole diff to figure out why you're contributing in the first place, you're less likely to get feedback and have your change -merged in. -+merged in. Also, split your changes into comprehensive chunks if you patch is ++merged in. Also, split your changes into comprehensive chunks if your patch is +longer than a dozen lines. - + If you are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR title that it's ---- @@ -306,17 +334,19 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit – only changes that are still unstaged. -This can be confusing, because if you've staged all of your changes, `git diff` will give you no output. +It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. +If you've staged all of your changes, `git diff` will give you no output. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. If our environment looks like this: +For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. +If our environment looks like this: [source,console] ---- $ git add CONTRIBUTING.md -$ echo 'test line' >> CONTRIBUTING.md +$ echo '# test line' >> CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -329,7 +359,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged +Now you can use `git diff` to see what is still unstaged: [source,console] ---- @@ -340,12 +370,12 @@ index 643e24f..87f08c8 100644 +++ b/CONTRIBUTING.md @@ -119,3 +119,4 @@ at the ## Starter Projects - + See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md). +# test line ---- -and `git diff --cached` to see what you've staged so far (--staged and --cached are synonyms): +and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): [source,console] ---- @@ -359,25 +389,27 @@ index 8ebb991..643e24f 100644 if we have to read the whole diff to figure out why you're contributing in the first place, you're less likely to get feedback and have your change -merged in. -+merged in. Also, split your changes into comprehensive chunks if you patch is ++merged in. Also, split your changes into comprehensive chunks if your patch is +longer than a dozen lines. - + If you are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR title that it's ---- -[[r_git_difftool]] [NOTE] .Git Diff in an External Tool ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like Araxis, emerge, vimdiff and more. Run `git difftool --tool-help` to see what is available on your system. +We will continue to use the `git diff` command in various ways throughout the rest of the book. +There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. +If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). +Run `git difftool --tool-help` to see what is available on your system. ==== -[[r_committing_changes]] +[[_committing_changes]] ==== Committing Your Changes Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged – any files you have created or modified that you haven't run `git add` on since you edited them – won't go into this commit. +Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. They will stay as modified files on your disk. In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) The simplest way to commit is to type `git commit`:(((git commands, commit))) @@ -388,10 +420,7 @@ $ git commit ---- Doing so launches your editor of choice. -(This is set by your shell's `$EDITOR` environment variable – usually vim or -emacs, although you can configure it with whatever you want using the `git config ---global core.editor` command as you saw in -<>).(((editor, changing default)))(((git commands, config))) +(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>).(((editor, changing default)))(((git commands, config))) The editor displays the following text (this example is a Vim screen): @@ -401,6 +430,8 @@ The editor displays the following text (this example is a Vim screen): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master +# Your branch is up-to-date with 'origin/master'. +# # Changes to be committed: # new file: README # modified: CONTRIBUTING.md @@ -417,7 +448,7 @@ You can remove these comments and type your commit message, or you can leave the Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: [source,console] ---- @@ -445,6 +476,7 @@ Adding the `-a` option to the `git commit` command makes Git automatically stage ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) @@ -457,16 +489,18 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit. +Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. +That's because the `-a` flag includes all changed files. +This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. -[[r_removing_files]] +[[_removing_files]] ==== Removing Files (((files, removing))) To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. -If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output: +If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: [source,console] ---- @@ -491,6 +525,7 @@ $ git rm PROJECTS.md rm 'PROJECTS.md' $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -498,7 +533,7 @@ Changes to be committed: ---- The next time you commit, the file will be gone and no longer tracked. -If you modified the file and added it to the index already, you must force the removal with the `-f` option. +If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. @@ -512,7 +547,7 @@ $ git rm --cached README ---- You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as +That means you can do things such as: [source,console] ---- @@ -529,18 +564,18 @@ Or, you can do something like this: $ git rm \*~ ---- -This command removes all files that end with `~`. +This command removes all files whose names end with a `~`. -[[r_git_mv]] +[[_git_mv]] ==== Moving Files (((files, moving))) Unlike many other VCS systems, Git doesn't explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact – we'll deal with detecting file movement a bit later. +However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like +If you want to rename a file in Git, you can run something like: [source,console] ---- @@ -555,6 +590,7 @@ In fact, if you run something like this and look at the status, you'll see that $ git mv README.md README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -571,5 +607,5 @@ $ git add README ---- Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `mv` is one command instead of three – it's a convenience function. -More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +The only real difference is that `git mv` is one command instead of three -- it's a convenience function. +More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. From cb7fe038be57cb4ca8df1b9b758ae1cd172e747d Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 18 Aug 2019 20:10:30 +0200 Subject: [PATCH 18/44] proseguito il lavoro sulla sezione recording MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit La traduzione della sezione recording-changes è arrivata al 25% circa --- .../sections/recording-changes.asc | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index e48751f..b4ea56d 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,66 @@ +//// === Recording Changes to the Repository +//// +=== Salvare le modifiche sul repository + +//// At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. +//// + +A questo punto dovresti avere un _autentico_ repository Git sul tuo computer e un checkout, ovvero una _copia di lavoro_, di tutti i suoi file di fronte a te. +Solitamente vorrai iniziare a fare modifiche e inviare gli snapshot di queste al tuo repository ogni volta che il progetto raggiunga uno stato che vuoi salvare. +//// Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about. +//// +Ricorda che ogni file della tua directory di lavoro può essere in uno dei due stati seguenti: _tracked_ (tracciato, ndt.) o _untracked_ (non tracciato, ndt.). +I file tracked sono già presenti nell'ultimo snapshot; possono quindi essere unmodified (non modificati, ndt.), modified (modificati, ndt.) o staged. +In breve i file tracked sono file che Git conosce. + +//// Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. +//// + +I file untracked sono tutti gli altri -- qualsiasi file nella tua directory di lavoro che non è presente nell'ultimo snapshot o nella tua area di stage. +Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché Git li ha appena prelevati e non hai modificato ancora niente. +//// As you edit files, Git sees them as modified, because you've changed them since your last commit. As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. +//// +Quando editi dei file, Git li vede come modificati, perché sono cambiati rispetto all'ultima commit. +Quando lavori, metti selettivamente nell'area di stage i file modificati e poi fai la commit di tutto ciò che è in quest'area, e quindi il ciclo si ripete. + +//// .The lifecycle of the status of your files. image::images/lifecycle.png[The lifecycle of the status of your files.] +//// + +.Il ciclo di vita dello stato dei tuoi file. +image::images/lifecycle.png[Il ciclo di vita dello stato dei tuoi file] + [[_checking_status]] +//// ==== Checking the Status of Your Files +//// +==== Controlla lo stato dei tuoi file +//// The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) If you run this command directly after a clone, you should see something like this: +//// + +Lo strumento principale che userai per determinare lo stato dei tuoi file è il comando `git status`.(((git commands, status))) +Se esegui questo comando appena dopo un clone, dovresti vedere qualcosa di simile: + [source,console] ---- @@ -30,14 +70,27 @@ Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- +//// This means you have a clean working directory; in other words, none of your tracked files are modified. Git also doesn't see any untracked files, or they would be listed here. Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. For now, that branch is always ``master'', which is the default; you won't worry about it here. <> will go over branches and references in detail. +//// + +Questo significa che hai una directory di lavoro pulita; ovvero che nessuno dei tuoi file tracciati è stato modificato. +Inoltre Git non ha trovato nessun file non ancora tracciato, altrimenti sarebbero elencati qui. +In aggiunta il comando indica anche in quale ramo sei e ti informa che non si è discostato dallo stesso ramo sul server. +Per ora il ramo è sempre `master`, che è il predefinito; non preoccupartene per adesso. +<> tratterà in dettagli dei `branch` (ramificazioni) e dei riferimenti. +//// Let's say you add a new file to your project, a simple `README` file. If the file didn't exist before, and you run `git status`, you see your untracked file like so: +//// + +Immagina di aver aggiunto un nuovo file al tuo progetto, un semplice README. +Se il file non esisteva e lanci `git status`, vedrai così il file non tracciato: [source,console] ---- @@ -53,23 +106,43 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- +//// You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including `README`, so let's start tracking the file. +//// + +Puoi vedere che il nuovo file README non è tracciato poiché nell'output è nella sezione dal titolo ``Untracked files''. +Untracked significa che Git vede un file che non avevi nello snapshot precedente (commit); Git non lo includerà negli snapshot delle tue commit fino a quando non glielo dirai esplicitamente. +Fa così per evitare che tu includa accidentalmente dei file binari generati o qualsiasi altro tipo di file che non intendi includere. +Se vuoi includere il file `README`, iniziamo a tracciarlo. + [[_tracking_files]] +//// ==== Tracking New Files +//// +==== Tracciare Nuovi File +//// In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) To begin tracking the `README` file, you can run this: +//// + +Per iniziare a tracciare un nuovo file, si usa il comando `git add`.(((git commands, add))) +Per tracciare il file `README`, usa questo comando: [source,console] ---- $ git add README ---- +//// If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: +//// + +Se lanci nuovamente il comando per lo stato, puoi vedere che il tuo file `README` ora è tracciato e nell'area di `stage` pronto per essere registrato: [source,console] ---- @@ -83,10 +156,17 @@ Changes to be committed: ---- +//// You can tell that it's staged because it's under the ``Changes to be committed'' heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +//// + +Sai che è nell'area di `stage` perché è nella sezione ``Changes to be committed''. +Se a questo punto fai commit, la versione del file com'era quando hai lanciato `git add` sarà quella che troverai nella successiva cronologia dello snapshot. +Ricorderai che quando prima hai eseguito `git init`, poi hai dovuto lanciare `git add ` -- che era necessario per iniziare a tracciare i file nella tua directory. +Il comando `git add` accetta il nome del percorso di un file o una directory; se è una directory, il comando aggiunge ricorsivamente tutti i file in quella directory. ==== Staging Modified Files From 685462c1efadacdaf15970d5ef3bd7a16a723537 Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 18 Aug 2019 20:27:46 +0200 Subject: [PATCH 19/44] aggiornata sezione recording aggiunto un a-capo per verificare la formattazione asciidoc --- book/02-git-basics/sections/recording-changes.asc | 1 + 1 file changed, 1 insertion(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index b4ea56d..3caf826 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -114,6 +114,7 @@ You do want to start including `README`, so let's start tracking the file. //// Puoi vedere che il nuovo file README non è tracciato poiché nell'output è nella sezione dal titolo ``Untracked files''. + Untracked significa che Git vede un file che non avevi nello snapshot precedente (commit); Git non lo includerà negli snapshot delle tue commit fino a quando non glielo dirai esplicitamente. Fa così per evitare che tu includa accidentalmente dei file binari generati o qualsiasi altro tipo di file che non intendi includere. Se vuoi includere il file `README`, iniziamo a tracciarlo. From cab7066a419fd86b73b21c37478341c2a5db5541 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 20 Aug 2019 13:35:41 +0200 Subject: [PATCH 20/44] continuata traduzione sezione recording-changes traduzione arrivata al 40% circa. Aggiunta la nuova traduzione del paragrafo su 'git status --short' che non esisteva in progit1 --- .../sections/recording-changes.asc | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 3caf826..480afcf 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -169,10 +169,18 @@ Se a questo punto fai commit, la versione del file com'era quando hai lanciato ` Ricorderai che quando prima hai eseguito `git init`, poi hai dovuto lanciare `git add ` -- che era necessario per iniziare a tracciare i file nella tua directory. Il comando `git add` accetta il nome del percorso di un file o una directory; se è una directory, il comando aggiunge ricorsivamente tutti i file in quella directory. +//// ==== Staging Modified Files +//// +==== Fare lo stage dei file modificati +//// Let's change a file that was already tracked. If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: +//// + +Modifichiamo un file che è già tracciato. +Se modifichi un file tracciato chiamato `CONTRIBUTING.md` e poi esegui il comando `git status`, otterrai qualcosa di simile a: [source,console] ---- @@ -192,11 +200,19 @@ Changes not staged for commit: ---- +//// The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command. `git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: +//// + +Il file `CONTRIBUTING.md` appare nella sezione chiamata ``Changes not staged for commit'' -- che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. +Per farlo, esegui il comando `git add`. +`git add` è un comando multifunzione -- lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose, ad esempio per segnare come risolti i conflitti causati da un `merge`. +Adesso esegui `git add` per mettere in `stage` il file `CONTRIBUTING.md`, e riesegui `git status`: + [source,console] ---- @@ -212,10 +228,17 @@ Changes to be committed: ---- +//// Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. You open it again and make that change, and you're ready to commit. However, let's run `git status` one more time: +//// + +Entrambi i file sono nello `stage` e rientreranno nella prossima commit. +A questo punto, immagina che ti sia ricordato di una piccola modifica da fare in `CONTRIBUTING.md` prima della commit. +Riapri il file e fai la modifica: ora sei pronto per la commit. +Come sempre, esegui `git status` un'altra volta: [source,console] ---- @@ -237,12 +260,21 @@ Changes not staged for commit: ---- +//// What the heck? Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +//// + +Cos'è successo? +Ora `CONTRIBUTING.md` è elencato sia dentro che fuori lo `stage`. +Come è possibile? +È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. +Se committi ora, la versione di `CONTRIBUTING.md` che verrà registrata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. +Se modifichi un file dopo che hai eseguito `git add`, devi rieseguire `git add` per mettere nello `stage` l'ultima versione del file: [source,console] ---- @@ -257,11 +289,20 @@ Changes to be committed: modified: CONTRIBUTING.md ---- +//// ==== Short Status +//// +==== Status in formato breve +//// While the `git status` output is pretty comprehensive, it's also quite wordy. Git also has a short status flag so you can see your changes in a more compact way. If you run `git status -s` or `git status --short` you get a far more simplified output from the command: +//// + +Anche se l'output di `git status` è abbastanza completo, è anche piuttosto prolisso. +Git però ha anche una opzione `short` di status così che si possono vedere le proprie modifiche in un modo più compatto. +Se esegui `git status -s` o `git status --short` ottieni dal comando un output molto più semplificato: [source,console] ---- @@ -273,10 +314,18 @@ M lib/simplegit.rb ?? LICENSE.txt ---- +//// New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +//// + +I nuovi file che non sono tracciati hanno un `??` accanto a loro, i nuovi file che sono stati aggiunti all'area di stage hanno una `A`, i file modificati hanno una `M` e così via. +Nell'output ci sono due colonne -- la colonna a sinistra indica lo stato dell'area di stage e la colonna a destra indica lo stato dell'albero di lavoro. +Così ad esempio, nel precedente output, il file `README` risulta modificato nella directory di lavoro ma non ancora inserito nell'area di stage, mentre il file `lib/simplegit.rb` é modificato ed inserito nell'area di stage. +Il file `Rakefile` é stato modificato, inserito nell'area di stage e poi modificato di nuovo. Quindi ci sono modifiche di questo file che sono sia nell'area di stage che al di fuori. + [[_ignoring]] ==== Ignoring Files From 98150b01d0a38b9c3d7bd6e94cf8d7449660997c Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 20 Aug 2019 23:45:54 +0200 Subject: [PATCH 21/44] arrivato al 50% di recording-changes --- .../sections/recording-changes.asc | 69 +++++++++++++++++-- 1 file changed, 63 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 480afcf..6067c66 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -328,12 +328,22 @@ Il file `Rakefile` é stato modificato, inserito nell'area di stage e poi modifi [[_ignoring]] +//// ==== Ignoring Files +//// +==== Ignorare File +//// Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) Here is an example `.gitignore` file: +//// + +Spesso hai dei file che non vuoi che Git aggiunga automaticamente e nemmeno che te li mostri come tracciati. +Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. +In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare.(((ignoring files))) +Questo è un file `.gitignore` di esempio: [source,console] ---- @@ -342,11 +352,19 @@ $ cat .gitignore *~ ---- +//// The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +//// + +La prima riga dice a Git di ignorare qualsiasi file che finisce in ``.o'' or ``.a'' -- file di oggetti o archivi che possono essere il prodotto di una compilazione del tuo codice. +La seconda riga dice a Git di ignorare tutti i file il cui nomefinisce con una tilde (`~`), che è usata da alcuni editor di testo come Emacs per marcare i file temporanei. +Puoi anche includere le directory log, tmp o pid, documenti generati automaticamente e così via. +Definire un file `.gitignore` per un tuo nuovo repository prima di iniziare è generalmente una buona idea, così eviti il rischio di registrare accidentalmente dei file che non vuoi nel tuo repository Git. +//// The rules for the patterns you can put in the `.gitignore` file are as follows: * Blank lines or lines starting with `#` are ignored. @@ -354,39 +372,66 @@ The rules for the patterns you can put in the `.gitignore` file are as follows: * You can start patterns with a forward slash (`/`) to avoid recursivity. * You can end patterns with a forward slash (`/`) to specify a directory. * You can negate a pattern by starting it with an exclamation point (`!`). +//// + +Queste sono le regole per i pattern che puoi usare in `.gitignore`: + +* Le righe vuote o che inizino con `#` vengono ignorate. +* Gli standard glob pattern funzionano (http://it.wikipedia.org/wiki/Glob_pattern, ndt) e saranno applicati ricorsivamente attraverso tutto l'intero albero di lavoro. +* Puoi iniziare i pattern con uno slash (`/`) per evitare la ricorsività. +* Puoi terminare i pattern con uno slash (`/`) per indicare una directory. +* Puoi negare un pattern facendolo iniziare con un punto esclamativo (`!`). +//// Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +//// +I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. +L'asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo (`?`) corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). +Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/**/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. + +//// Here is another example `.gitignore` file: +//// + +Questo è un altro esempio di file `.gitignore`: [source] ---- -# ignore all .a files +# ignora tutti i file .a *.a -# but do track lib.a, even though you're ignoring .a files above +# ma traccia lib.a, sebbene tu stia ignorando tutti i file .a !lib.a -# only ignore the TODO file in the current directory, not subdir/TODO +# ignora solo il TODO nella root, e non subdir/TOD /TODO -# ignore all files in any directory named build +# ignora tutti i file in ogni directory denominata build build/ -# ignore doc/notes.txt, but not doc/server/arch.txt +# ignora doc/note.txt, ma non doc/server/arch.txt doc/*.txt -# ignore all .pdf files in the doc/ directory and any of its subdirectories +# ignora tutti i file .pdf nella directory doc/ ed in ognuna delle sue sottodirectory doc/**/*.pdf ---- +//// [TIP] ==== GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. ==== +//// + +[TIP] +==== +Se desideri un punto di partenza per i tuoi progetti, GitHub mantiene un elenco abbastanza completo di ottimi esempi di file `.gitignore` per decine di progetti e linguaggi all'URL https://github.com/github/gitignore[]. +==== +//// [NOTE] ==== In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. @@ -396,6 +441,18 @@ The rules in these nested `.gitignore` files apply only to the files under the d It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. ==== +//// + +[NOTE] +==== +In un caso semplice, un repository potrebbe avere un singolo file `.gitignore` nella propria directory radice, che si applica ricorsivamente all'intero repository. +Comunque, è anche possibile avere ulteriori file `.gitignore` nelle sottodirectory. +Le regole di questi `.gitignore` nidificati si applicano soltanto ai file contenuti nella directory in cui il `.gitignore` è posizionato. +(Il repository del codice sorgente del kernel Linux ha 206 file `.gitignore`.) + +E' oltre gli scopi di questo libro entrare nei dettagli dei file `.gitignore` multipli; per i dettagli vedi `man gitignore`. +==== + [[_git_diff_staged]] ==== Viewing Your Staged and Unstaged Changes From d31a51e5a7206218aa23ec21d9f62ac302b61a46 Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 21 Aug 2019 14:16:15 +0200 Subject: [PATCH 22/44] avanzamento al 65% della traduzione di recording-changes --- .../sections/recording-changes.asc | 55 ++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 6067c66..d653139 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -450,13 +450,17 @@ Comunque, è anche possibile avere ulteriori file `.gitignore` nelle sottodirect Le regole di questi `.gitignore` nidificati si applicano soltanto ai file contenuti nella directory in cui il `.gitignore` è posizionato. (Il repository del codice sorgente del kernel Linux ha 206 file `.gitignore`.) -E' oltre gli scopi di questo libro entrare nei dettagli dei file `.gitignore` multipli; per i dettagli vedi `man gitignore`. +È oltre gli scopi di questo libro entrare nei dettagli dei file `.gitignore` multipli; per i dettagli vedi `man gitignore`. ==== [[_git_diff_staged]] +//// ==== Viewing Your Staged and Unstaged Changes +//// +==== Mostra le modifiche dentro e fuori lo `stage` +//// If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? @@ -464,6 +468,14 @@ Although `git status` answers those questions very generally by listing the file Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. If you run your `git status` command, you once again see something like this: +//// + +Se `git status` è troppo vago per te -- vuoi sapere cos'è stato effettivamente modificato e non solo quali file -- puoi usare il comando `git diff`.(((git commands, diff))) +Tratteremo più avanti `git diff` con maggior dettaglio, ma probabilmente lo userai molto spesso per rispondere a queste due domande: Cos'è che hai modificato ma non è ancora in `stage`? +E cos'hai nello `stage` che non hai ancora registrato con commit? +Sebbene `git status` risponda a queste domande in modo genericoelencando i nomi dei file, `git diff` mostra le righe effettivamente aggiunte e rimosse -- la patch così com'è. + +Supponiamo che tu abbia modificato nuovamente `README` e `CONTRIBUTING.md` ma messo nello `stage` solo il primo. Se esegui il comando `git status`, vedrai qualcosa come questo: [source,console] ---- @@ -482,7 +494,11 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- +//// To see what you've changed but not yet staged, type `git diff` with no other arguments: +//// + +Per vedere cosa hai modificato, ma non ancora inserito nell'area di `stage`, digita `git diff` senza altri argomenti: [source,console] ---- @@ -503,11 +519,19 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- +//// That command compares what is in your working directory with what is in your staging area. The result tells you the changes you've made that you haven't yet staged. If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. This command compares your staged changes to your last commit: +//// + +Questo comando confronta cosa c'è nella tua directory di lavoro con quello che c'è nella tua area di `stage`. +Il risultato mostra le tue modifiche che ancora non hai messo nello `stage`. + +Se vuoi vedere cosa c'è nello `stage` e che farà parte della prossima commit, puoi usare `git diff --staged`. +Questo comando confronta le modifiche che hai nell'area di `stage` e la tua ultima commit: [source,console] ---- @@ -521,11 +545,21 @@ index 0000000..03902a1 +My Project ---- +//// It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. If you've staged all of your changes, `git diff` will give you no output. +//// + +È importante notare che `git diff` di per se non visualizza tutte le modifiche fatte dall'ultima commit, ma solo quelle che non sono ancora in `stage`. +Se hai messo in `stage` tutte le tue modifiche, `git diff` non mostrerà nulla. +//// For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. If our environment looks like this: +//// + +Ecco un altro esempio, se metti in `stage` il file `CONTRIBUTING.md` e lo modifichi, puoi usare `git diff` per vedere quali modifiche al file sono in stage e i quali non ancora. +Se il nostro ambiente assomiglia a questo: [source,console] ---- @@ -546,7 +580,11 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- +//// Now you can use `git diff` to see what is still unstaged: +//// + +Allora puoi usare `git diff` per vedere cosa non è ancora in `stage` [source,console] ---- @@ -562,7 +600,11 @@ index 643e24f..87f08c8 100644 +# test line ---- +//// and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): +//// + +e `git diff --cached` per vedere cos'è già in `stage` (`--staged` e `--cached` sono sinonimi) [source,console] ---- @@ -583,6 +625,7 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- +//// [NOTE] .Git Diff in an External Tool ==== @@ -591,6 +634,16 @@ There is another way to look at these diffs if you prefer a graphical or externa If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). Run `git difftool --tool-help` to see what is available on your system. ==== +//// + +[NOTE] +.Git Diff in uno Strumento Esterno +==== +Continueremo ad utilizzare il comando `git diff` in vari modi attraverso il resto del libro. +Se invece preferisci un programma grafico o un visualizzatore esterno di differenze c'é un altro modo per visionare queste diff. +Se esegui `git difftool` invece di `git diff`, puoi visualizzare la singola diff in software come emerge, vimdiff e molti altri (inclusi prodotti commerciali). +Esegui `git difftool --tool-help` per vedere cos'é disponibile sul tuo sistema. +==== [[_committing_changes]] ==== Committing Your Changes From 9e9148e1d3d268439e1ec10d56f0a53e1cd2c69d Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 21 Aug 2019 23:12:26 +0200 Subject: [PATCH 23/44] traduzione di recording all'80% MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit in tutta questa sezione ho sostituito il neologismo "committare" con formule alternative (es registrare con commit) perchè mi sembrava che la resa in italiano non fosse il massimo sia grammaticalmente che foneticamente --- .../sections/recording-changes.asc | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index d653139..35cd581 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -646,23 +646,41 @@ Esegui `git difftool --tool-help` per vedere cos'é disponibile sul tuo sistema. ==== [[_committing_changes]] +//// ==== Committing Your Changes +//// +==== Registra con commit le tu modifiche +//// Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. They will stay as modified files on your disk. In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) The simplest way to commit is to type `git commit`:(((git commands, commit))) +//// + +Ora che la tua area di stage è configurata come vuoi, puoi fare l'operazione di commit delle tue modifiche. +Ricorda che tutto ciò che non è in `stage` -- qualsiasi file che hai creato o modificato per cui non hai fatto `git add` -- non sarà nell'operazione di commit. +Rimarranno come file modificati sul tuo disco. +In questo caso, l'ultima volta che hai eseguito `git status`, hai visto che tutto era in `stage`, così sei pronto a registrare con committ le tue modifiche.(((git commands, status))) +Il modo più semplice per farlo è eseguire `git commit`:(((git commands, commit))) [source,console] ---- $ git commit ---- +//// Doing so launches your editor of choice. (This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>).(((editor, changing default)))(((git commands, config))) The editor displays the following text (this example is a Vim screen): +//// + +Facendolo lanci il tuo editor predefinito. +(Questo è impostato nella tua shell con la variabile di ambiente `EDITOR` -- generalmente vim o emacs, sebbene tu possa configurarlo con qualsiasi altro editor, usando il comando `git config --global core.editor` come hai visto nel <>).(((editor, changing default)))(((git commands, config))) + +L'editor visualizzerà il testo (questo è un esempio della schermata di Vim): [source] ---- @@ -682,6 +700,7 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- +//// You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. (For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. @@ -689,6 +708,15 @@ Doing so also puts the diff of your change in the editor so you can see exactly When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: +//// + +Come vedi, il messaggio predefinito della commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. +Puoi rimuovere questi commenti e inserire il tuo messaggio di commit, o puoi lasciarli così per aiutarti a ricordare cosa registrando con commit. +(Per un promemoria ancora più esplicito puoi usare l'opzione `-v` con `git commit`. +Facendo così saranno inserite nel commento anche le modifiche stesse, così che tu possa vedere esattamente quali modifiche stai registrando). +Quando esci dall'editor, Git crea la tua commit con il proprio messaggio (rimuovendo commenti ed eventuali diff). + +In alternativa, puoi digitare il tuo messaggio per la commit, sulla riga di comando della `commit` stessa, specificandolo dopo l'opzione -m, come segue: [source,console] ---- @@ -698,12 +726,22 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- +//// Now you've created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. Remember that the commit records the snapshot you set up in your staging area. Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +//// + +Hai creato la tua prima commit! +Puoi vedere che la commit restituisce alcune informazioni su se stessa: su quale `branch` (ramo, ndt) hai fatto la commit (`master`), quale checksum SHA-1 ha la commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle righe aggiunte e rimosse con la commit. + +Ricorda che la commit registra lo snapshot che hai salvato nella tua area di `stage`. +Qualsiasi cosa che non è nello `stage` rimarrà lì come modificata; puoi fare un'altra commit per aggiungerli alla tua cronologia. +Ogni volta che fai una commit, stai salvando un'istantanea (`snapshot`) del tuo progetto che puoi ripristinare o confrontare in seguito. + ==== Skipping the Staging Area From f414a150a904b7f5a3de0b0f2a19de6c39d013d2 Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 21 Aug 2019 23:30:21 +0200 Subject: [PATCH 24/44] corrette alcune parole --- book/02-git-basics/sections/recording-changes.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 35cd581..e071689 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -649,7 +649,7 @@ Esegui `git difftool --tool-help` per vedere cos'é disponibile sul tuo sistema. //// ==== Committing Your Changes //// -==== Registra con commit le tu modifiche +==== Registra con commit le tue modifiche //// Now that your staging area is set up the way you want it, you can commit your changes. @@ -711,7 +711,7 @@ Alternatively, you can type your commit message inline with the `commit` command //// Come vedi, il messaggio predefinito della commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. -Puoi rimuovere questi commenti e inserire il tuo messaggio di commit, o puoi lasciarli così per aiutarti a ricordare cosa registrando con commit. +Puoi rimuovere questi commenti e inserire il tuo messaggio di commit, o puoi lasciarli così per aiutarti a ricordare cosa stai registrando con commit. (Per un promemoria ancora più esplicito puoi usare l'opzione `-v` con `git commit`. Facendo così saranno inserite nel commento anche le modifiche stesse, così che tu possa vedere esattamente quali modifiche stai registrando). Quando esci dall'editor, Git crea la tua commit con il proprio messaggio (rimuovendo commenti ed eventuali diff). From 915071b35ef18f5bfbb500327228548adee39f72 Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 22 Aug 2019 14:40:01 +0200 Subject: [PATCH 25/44] aggiunto altro piccolo pezzo di traduzione di recording --- book/02-git-basics/sections/recording-changes.asc | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index e071689..0c55074 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -743,12 +743,21 @@ Qualsiasi cosa che non è nello `stage` rimarrà lì come modificata; puoi fare Ogni volta che fai una commit, stai salvando un'istantanea (`snapshot`) del tuo progetto che puoi ripristinare o confrontare in seguito. +//// ==== Skipping the Staging Area +//// +==== Saltare l'Area di Stage (((staging area, skipping))) +//// Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +//// + +Sebbene sia estremamente utile per amministrare le commit esattamente come vuoi, l'area di stage è molto più complessa di quanto tu possa necessitare nel lavoro normale. +Se vuoi saltare l'area di `stage`, Git fornisce una semplice sccorciatoia. +Aggiungendo l'opzione `-a` al comando `git commit`, Git, prima di eseguire la commit, mette automaticamente nello `stage` tutti i file che erano già tracciati, permettendoti di saltare la parte `git add`: [source,console] ---- @@ -767,9 +776,15 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- +//// Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. That's because the `-a` flag includes all changed files. This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. +//// + +Nota come in questo caso non hai bisogno di eseguire `git add` per `CONTRIBUTING.md` prima della commit. +Questo perchè l'opzione `-a` include tutti i file modificati. +Questo è conveniente, ma attenzione: a volte questa opzione potrebbe causare l'inclusione di modifiche non volute. [[_removing_files]] ==== Removing Files From d57d66282de1192e911e8faf0d5676d6130d626a Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 22 Aug 2019 19:55:44 +0200 Subject: [PATCH 26/44] completata finalmente la sezione recording-changes --- .../sections/recording-changes.asc | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 0c55074..414c3d3 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -787,13 +787,23 @@ Questo perchè l'opzione `-a` include tutti i file modificati. Questo è conveniente, ma attenzione: a volte questa opzione potrebbe causare l'inclusione di modifiche non volute. [[_removing_files]] +//// ==== Removing Files +//// +==== Rimuovere i File (((files, removing))) +//// To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: +//// + +Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente, rimuoverlo dall'area di `stage`) e quindi registrare con commit. +Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato. + +Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione ``Changes not staged for commit'' (cioè, _no in `stage`_) dell'output `git status`: [source,console] ---- @@ -810,7 +820,12 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- +//// Then, if you run `git rm`, it stages the file's removal: +//// + +Se poi esegui `git rm`, la rimozione del file viene messa nello `stage`: + [source,console] ---- @@ -825,6 +840,7 @@ Changes to be committed: deleted: PROJECTS.md ---- +//// The next time you commit, the file will be gone and no longer tracked. If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. @@ -833,50 +849,93 @@ Another useful thing you may want to do is to keep the file in your working tree In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option: +//// + +La prossima volta che registrerai una commit, il file sparirà e non sarà più tracciato. +Se avevi già modificato il file o lo avevi aggiunto all'area di stage, devi forzarne la rimozione con l'opzione `-f`. +Questa è una misura di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati salvati in uno `snapshot` e che non potrebbero essere recuperati con Git. + +Un'altra cosa utile che potresti voler fare è mantenere il file nel tuo ambiente di di lavoro ma rimuoverlo dall'area di `stage`. +In altre parole, vuoi mantenere il file sul tuo disco ma non vuoi che Git continui a tracciarlo. +Questo è particolarmente utile se hai dimenticato di aggiungere qualcosa al tuo `.gitignore` e accidentalmente lo metti in `stage`, come un file di log molto grande o un sacco di file compilati `.a`. +Per farlo usa l'opzione `--cached`: [source,console] ---- $ git rm --cached README ---- +//// You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as: +//// + +Puoi passare file, directory o pattern glob di file al comando `git rm`. +Questo significa che puoi fare: [source,console] ---- $ git rm log/\*.log ---- +//// Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this: +//// + +Nota la barra inversa (`\`) prima di `*`. +Questo è necessario perché Git ha un'espansione propria dei nomi di file oltre a quella della tua shell. +Questo comando rimuove tutti i file che hanno l'estensione `.log` nella directory `log/`. +Oppure, puoi fare qualcosa di questo tipo: [source,console] ---- $ git rm \*~ ---- +//// This command removes all files whose names end with a `~`. +//// + +Questo comando rimuove tutti i file il cui nome termina con una `~`. [[_git_mv]] +//// ==== Moving Files +//// +==== Spostare i File (((files, moving))) +//// Unlike many other VCS systems, Git doesn't explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. Thus it's a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like: +//// + +A differenza di altri sistemi VCS, Git non traccia esplicitamente gli spostamenti dei file. +Se rinomini un file in Git, nessun metadato viene salvato per dirgli che lo hai rinominato. +Tuttavia, Git è abbastanza intelligente da capirlo dopo che l'hai fatto -- più in la ci occuperemo di rilevare il movimento dei file. + +Perciò può creare un po' di confusione il fatto che Git abbia un comando `mv`. +Se vuoi rinominare un file in Git puoi eseguire qualcosa come: [source,console] ---- $ git mv file_from file_to ---- +//// and it works fine. In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +//// + +e funziona bene. +Se, infatti, lanci un comando del genere e controlli lo stato, vedrai che Git considera il file rinominato: [source,console] ---- @@ -890,7 +949,11 @@ Changes to be committed: renamed: README.md -> README ---- +//// However, this is equivalent to running something like this: +//// + +Comunque, questo è equivalente ad eseguire qualcosa come: [source,console] ---- @@ -899,6 +962,12 @@ $ git rm README.md $ git add README ---- +//// Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. The only real difference is that `git mv` is one command instead of three -- it's a convenience function. More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +//// + +Git capisce che implicitamente stai rinominando il file, così che non c'è differenza tra rinominare un file in questo modo o con il comando `mv`. +L'unica differenza reale è che `mv` è un solo comando invece di tre -- è un questione di convenienza. +Ciò che più conta è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit. From a06d59247d850a11f7010f185823e3751819d95f Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 22 Aug 2019 20:28:40 +0200 Subject: [PATCH 27/44] correzioni di alcune parole e tag asciidoc --- book/02-git-basics/sections/recording-changes.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 414c3d3..dbf21b5 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -208,7 +208,7 @@ It may be helpful to think of it more as ``add precisely this content to the nex Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: //// -Il file `CONTRIBUTING.md` appare nella sezione chiamata ``Changes not staged for commit'' -- che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. +Il file `CONTRIBUTING.md` appare nella sezione chiamata ``Changes not staged for commit'' -- che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add`. `git add` è un comando multifunzione -- lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose, ad esempio per segnare come risolti i conflitti causati da un `merge`. Adesso esegui `git add` per mettere in `stage` il file `CONTRIBUTING.md`, e riesegui `git status`: @@ -236,7 +236,7 @@ However, let's run `git status` one more time: //// Entrambi i file sono nello `stage` e rientreranno nella prossima commit. -A questo punto, immagina che ti sia ricordato di una piccola modifica da fare in `CONTRIBUTING.md` prima della commit. +A questo punto, immagina di esserti ricordato di una piccola modifica da fare in `CONTRIBUTING.md` prima della commit. Riapri il file e fai la modifica: ora sei pronto per la commit. Come sempre, esegui `git status` un'altra volta: @@ -389,8 +389,8 @@ You can also use two asterisks to match nested directories; `a/**/z` would match //// I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. -L'asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo (`?`) corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). -Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/**/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. +L'asterisco `\*` corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo `?` corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno `\[0-9\]` corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). +Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/\*\*/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. //// Here is another example `.gitignore` file: @@ -803,7 +803,7 @@ If you simply remove the file from your working directory, it shows up under the Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente, rimuoverlo dall'area di `stage`) e quindi registrare con commit. Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato. -Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione ``Changes not staged for commit'' (cioè, _no in `stage`_) dell'output `git status`: +Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione ``Changes not staged for commit'' (cioè, _no in `stage`_) dell'output `git status`: [source,console] ---- From f1a6bccabb8d32f8d371b5b00c402bdfa05ea48c Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 22 Aug 2019 20:32:52 +0200 Subject: [PATCH 28/44] minime correzioni dei tag asciidoc --- book/02-git-basics/sections/recording-changes.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index dbf21b5..8052bb7 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -389,8 +389,8 @@ You can also use two asterisks to match nested directories; `a/**/z` would match //// I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. -L'asterisco `\*` corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo `?` corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno `\[0-9\]` corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). -Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/\*\*/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. +L'asterisco `\*` corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo `?` corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno `[0-9]` corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). +Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/**/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. //// Here is another example `.gitignore` file: From 16bb2a8052955500d1cd1abb7de33b9730bb23bb Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 27 Aug 2019 19:17:12 +0200 Subject: [PATCH 29/44] prima parte di traduzione di viewing --- .../sections/viewing-history.asc | 151 ++++++++++++++---- 1 file changed, 123 insertions(+), 28 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 21b6aac..1ed1c34 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,33 @@ -[[r_viewing_history]] +[[_viewing_history]] +//// === Viewing the Commit History +//// +=== Vedere la Cronologia delle Commit +//// After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command. These examples use a very simple project called ``simplegit''. To get the project, run +//// + +Dopo che avrai creato un po' di commit, o se hai clonato un repository che già ha la sua cronologia di commit, vorrai probabilmente guardare cos'è successo nel passato. +Lo strumento essenziale e quello più potente per farlo è il comando `git log`. + +Questi esempi usano un progetto veramente semplice chiamato ``simplegit''. +Per ottenere il progetto, esegui [source,console] ---- -git clone https://github.com/schacon/simplegit-progit +$ git clone https://github.com/schacon/simplegit-progit ---- +//// When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +//// + +Quando esegui `git log` in questo progetto, dovresti avere un output che assomiglia a questo:(((git commands, log))) [source,console] ---- @@ -36,14 +51,25 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order – that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and e-mail, the date written, and the commit message. +//// +By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. +As you can see, this command lists each commit with its SHA-1 checksum, the author's name and email, the date written, and the commit message. A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. Here, we'll show you some of the most popular. -One of the more helpful options is `-p`, which shows the difference introduced in each commit. -You can also use `-2`, which limits the output to only the last two entries: +One of the more helpful options is `-p` or `--patch`, which shows the difference (the _patch_ output) introduced in each commit. +You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries. +//// + +In modo predefinito, senza argomenti, `git log` mostra le commit fatte nel repository in ordine cronologico inverso, in questo modo la commit più recente è la prima ad apparire. +Come vedi, questo comando elenca ogni commit con il suo codice SHA-1, il nome e l'email dell'autore, la data di salvataggio e il messaggio della commit. + +Sono disponibili moltissime opzioni da passare al comando `git log` per mostrare esattamente quello che stai cercando. +Qui ne vedremo alcune tra quelle più famose. + +Una delle opzioni più utili è `-p` o `--patch`, che mostra le differenze (l'output _patch_) introdotte da ciascuna commit. +Puoi anche limitare il numero delle voci visualizzate, ad esempio utilizzando `-2` per mostrare solo le ultime due voci. [source,console] ---- @@ -87,13 +113,20 @@ index a0a60ae..47c6340 100644 - git = SimpleGit.new - puts git.show -end -\ No newline at end of file ---- +//// This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +//// + +Quest'opzione mostra le stessi informazioni ma ciascun elemento è seguito dalle differenze. +Questo è molto utile per revisionare il codice o per dare un'occhiata veloce a cosa è successo in una serie di commit che un collaboratore ha aggiunto. + +Puoi usare anche una serie di opzioni di riassunto con `git log`. +Per esempio, se vuoi vedere alcune statistiche brevi per ciascuna commit, puoi usare l'opzione `--stat`: [source,console] ---- @@ -128,14 +161,27 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- +//// As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. +//// +Come puoi vedere, l'opzione `--stat` visualizza sotto ogni commit la lista dei file modificati, quanti file sono stati modificati, e quante righe in questi file sono state aggiunte e rimosse. +Alla fine aggiunge anche un resoconto delle informazioni. + +//// Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +//// + +Un'altra opzione veramente utile è `--pretty`. +Questa opzione modifica gli output di log rispetto a quella predefinita. +Alcune opzioni predefinite sono pronte all'uso. +L'opzione `oneline` visualizza ogni commit su una singola linea, che è utile se stai controllando una lunga serie di commit. +In aggiunta le opzioni `short`, `full` e `fuller` mostrano più o meno lo stesso output ma con più o meno informazioni, rispettivamente: [source,console] ---- @@ -145,8 +191,13 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- +//// The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing – because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +This is especially useful when you're generating output for machine parsing -- because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +//// + +L'opzione più interessante è `format`, che ti permette di specificare la formattazione dell'output di log. +Questa è estremamente utile quando stai generando un output che sarà sottoposto ad analisi automatica -- perché specificando esplicitamente il formato, sai che non cambierà con gli aggiornamenti di Git:(((log formatting))) [source,console] ---- @@ -156,9 +207,14 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> lists some of the more useful options that format takes. +//// +<> lists some of the more useful options that `format` takes. +//// + +<> elenca alcune delle opzioni maggiormente utili che `format` accetta. -[[rpretty_format]] +//// +[[pretty_format]] .Useful options for `git log --pretty=format` [cols="1,4",options="header"] |================================ @@ -170,8 +226,31 @@ a11bef0 - Scott Chacon, 6 years ago : first commit | `%P` | Parent hashes | `%p` | Abbreviated parent hashes | `%an` | Author name -| `%ae` | Author e-mail -| `%ad` | Author date (format respects the –date= option) +| `%ae` | Author email +| `%ad` | Author date (format respects the --date=option) +| `%ar` | Author date, relative +| `%cn` | Committer name +| `%ce` | Committer email +| `%cd` | Committer date +| `%cr` | Committer date, relative +| `%s` | Subject +|================================ +//// + +[[pretty_format]] +.Opzioni utili per `git log --pretty=format` +[cols="1,4",options="header"] +|================================ +| Opzione | Descrizione dell'Output +| `%H` | Hash della commit +| `%h` | Abbreviated commit hash +| `%T` | Tree hash +| `%t` | Abbreviated tree hash +| `%P` | Parent hashes +| `%p` | Abbreviated parent hashes +| `%an` | Author name +| `%ae` | Author email +| `%ad` | Author date (format respects the --date=option) | `%ar` | Author date, relative | `%cn` | Committer name | `%ce` | Committer email @@ -182,10 +261,10 @@ a11bef0 - Scott Chacon, 6 years ago : first commit You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit – you as the author, and the core member as the committer. +So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer. We'll cover this distinction a bit more in <>. -The oneline and format options are particularly useful with another `log` option called `--graph`. +The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history: [source,console] @@ -205,10 +284,10 @@ $ git log --pretty=format:"%h %s" --graph This type of output will become more interesting as we go through branching and merging in the next chapter. -Those are only some simple output-formatting options to `git log` – there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +Those are only some simple output-formatting options to `git log` -- there are many more. +<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. -[[rlog_options]] +[[log_options]] .Common options to `git log` [cols="1,4",options="header"] |================================ @@ -222,12 +301,13 @@ Those are only some simple output-formatting options to `git log` – there are | `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. | `--graph` | Display an ASCII graph of the branch and merge history beside the log output. | `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). +| `--oneline` | Shorthand for `--pretty=oneline --abbrev-commit` used together. |================================ ==== Limiting Log Output -In addition to output-formatting options, `git log` takes a number of useful limiting options – that is, options that let you show only a subset of commits. -You've seen one such option already – the `-2` option, which show only the last two commits. +In addition to output-formatting options, `git log` takes a number of useful limiting options; that is, options that let you show only a subset of commits. +You've seen one such option already -- the `-2` option, which displays only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. @@ -239,31 +319,39 @@ For example, this command gets the list of commits made in the last two weeks: $ git log --since=2.weeks ---- -This command works with lots of formats – you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +This command works with lots of formats -- you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. -(Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) -Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string. For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +[NOTE] +==== +You can specify more than one instance of both the `--author` and `--grep` search criteria, which +will limit the commit output to commits that match _any_ of the `--author` patterns and _any_ +of the `--grep` patterns; however, adding the `--all-match` option further limits the output to +just those commits that match _all_ `--grep` patterns. +==== + +Another really helpful filter is the `-S` option (colloquially referred to as Git's ``pickaxe'' option), which takes a string and shows only those commits that changed the number of occurrences of that string. +For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: [source,console] ---- -$ git log -Sfunction_name +$ git log -S function_name ---- The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. -In <> we'll list these and a few other common options for your reference. +In <> we'll list these and a few other common options for your reference. -[[rlimit_options]] +[[limit_options]] .Options to limit the output of `git log` [cols="2,4",options="header"] |================================ | Option | Description -| `-(n)` | Show only the last n commits +| `-` | Show only the last n commits | `--since`, `--after` | Limit the commits to those made after the specified date. | `--until`, `--before` | Limit the commits to those made before the specified date. | `--author` | Only show commits in which the author entry matches the specified string. @@ -272,11 +360,11 @@ In <> we'll list these and a few other common options for your r | `-S` | Only show commits adding or removing code matching the string |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:(((log filtering))) +For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering))) [source,console] ---- -$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ +$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attributes are in use acd3b9e - Enhance hold_lock_file_for_{update,append}() API @@ -287,3 +375,10 @@ b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unbor ---- Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. + +[TIP] +.Preventing the display of merge commits +==== +Depending on the workflow used in your repository, it's possible that a sizable percentage of the commits in your log history are just merge commits, which typically aren't very informative. +To prevent the display of merge commits cluttering up your log history, simply add the log option `--no-merges`. +==== From 391f83c6ed1434b20fc6791aebc8e62e290eb10c Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 28 Aug 2019 20:46:53 +0200 Subject: [PATCH 30/44] rimossi i commenti in recording --- .../sections/recording-changes.asc | 355 ------------------ 1 file changed, 355 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 8052bb7..37d5159 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,63 +1,25 @@ -//// -=== Recording Changes to the Repository -//// - === Salvare le modifiche sul repository -//// -At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. -Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. -//// - A questo punto dovresti avere un _autentico_ repository Git sul tuo computer e un checkout, ovvero una _copia di lavoro_, di tutti i suoi file di fronte a te. Solitamente vorrai iniziare a fare modifiche e inviare gli snapshot di queste al tuo repository ogni volta che il progetto raggiunga uno stato che vuoi salvare. -//// -Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -In short, tracked files are files that Git knows about. -//// - Ricorda che ogni file della tua directory di lavoro può essere in uno dei due stati seguenti: _tracked_ (tracciato, ndt.) o _untracked_ (non tracciato, ndt.). I file tracked sono già presenti nell'ultimo snapshot; possono quindi essere unmodified (non modificati, ndt.), modified (modificati, ndt.) o staged. In breve i file tracked sono file che Git conosce. -//// -Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. -//// - I file untracked sono tutti gli altri -- qualsiasi file nella tua directory di lavoro che non è presente nell'ultimo snapshot o nella tua area di stage. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché Git li ha appena prelevati e non hai modificato ancora niente. -//// -As you edit files, Git sees them as modified, because you've changed them since your last commit. -As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. -//// - Quando editi dei file, Git li vede come modificati, perché sono cambiati rispetto all'ultima commit. Quando lavori, metti selettivamente nell'area di stage i file modificati e poi fai la commit di tutto ciò che è in quest'area, e quindi il ciclo si ripete. -//// -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] -//// - .Il ciclo di vita dello stato dei tuoi file. image::images/lifecycle.png[Il ciclo di vita dello stato dei tuoi file] [[_checking_status]] -//// -==== Checking the Status of Your Files -//// ==== Controlla lo stato dei tuoi file -//// -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: -//// - Lo strumento principale che userai per determinare lo stato dei tuoi file è il comando `git status`.(((git commands, status))) Se esegui questo comando appena dopo un clone, dovresti vedere qualcosa di simile: @@ -70,25 +32,12 @@ Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- -//// -This means you have a clean working directory; in other words, none of your tracked files are modified. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<> will go over branches and references in detail. -//// - Questo significa che hai una directory di lavoro pulita; ovvero che nessuno dei tuoi file tracciati è stato modificato. Inoltre Git non ha trovato nessun file non ancora tracciato, altrimenti sarebbero elencati qui. In aggiunta il comando indica anche in quale ramo sei e ti informa che non si è discostato dallo stesso ramo sul server. Per ora il ramo è sempre `master`, che è il predefinito; non preoccupartene per adesso. <> tratterà in dettagli dei `branch` (ramificazioni) e dei riferimenti. -//// -Let's say you add a new file to your project, a simple `README` file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: -//// - Immagina di aver aggiunto un nuovo file al tuo progetto, un semplice README. Se il file non esisteva e lanci `git status`, vedrai così il file non tracciato: @@ -106,13 +55,6 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -//// -You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including `README`, so let's start tracking the file. -//// - Puoi vedere che il nuovo file README non è tracciato poiché nell'output è nella sezione dal titolo ``Untracked files''. Untracked significa che Git vede un file che non avevi nello snapshot precedente (commit); Git non lo includerà negli snapshot delle tue commit fino a quando non glielo dirai esplicitamente. @@ -121,16 +63,8 @@ Se vuoi includere il file `README`, iniziamo a tracciarlo. [[_tracking_files]] -//// -==== Tracking New Files -//// ==== Tracciare Nuovi File -//// -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the `README` file, you can run this: -//// - Per iniziare a tracciare un nuovo file, si usa il comando `git add`.(((git commands, add))) Per tracciare il file `README`, usa questo comando: @@ -139,10 +73,6 @@ Per tracciare il file `README`, usa questo comando: $ git add README ---- -//// -If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: -//// - Se lanci nuovamente il comando per lo stato, puoi vedere che il tuo file `README` ora è tracciato e nell'area di `stage` pronto per essere registrato: [source,console] @@ -157,28 +87,13 @@ Changes to be committed: ---- -//// -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. -//// - Sai che è nell'area di `stage` perché è nella sezione ``Changes to be committed''. Se a questo punto fai commit, la versione del file com'era quando hai lanciato `git add` sarà quella che troverai nella successiva cronologia dello snapshot. Ricorderai che quando prima hai eseguito `git init`, poi hai dovuto lanciare `git add ` -- che era necessario per iniziare a tracciare i file nella tua directory. Il comando `git add` accetta il nome del percorso di un file o una directory; se è una directory, il comando aggiunge ricorsivamente tutti i file in quella directory. -//// -==== Staging Modified Files -//// ==== Fare lo stage dei file modificati -//// -Let's change a file that was already tracked. -If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: -//// - Modifichiamo un file che è già tracciato. Se modifichi un file tracciato chiamato `CONTRIBUTING.md` e poi esegui il comando `git status`, otterrai qualcosa di simile a: @@ -200,14 +115,6 @@ Changes not staged for commit: ---- -//// -The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. -`git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. -It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: -//// - Il file `CONTRIBUTING.md` appare nella sezione chiamata ``Changes not staged for commit'' -- che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add`. `git add` è un comando multifunzione -- lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose, ad esempio per segnare come risolti i conflitti causati da un `merge`. @@ -228,13 +135,6 @@ Changes to be committed: ---- -//// -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: -//// - Entrambi i file sono nello `stage` e rientreranno nella prossima commit. A questo punto, immagina di esserti ricordato di una piccola modifica da fare in `CONTRIBUTING.md` prima della commit. Riapri il file e fai la modifica: ora sei pronto per la commit. @@ -260,15 +160,6 @@ Changes not staged for commit: ---- -//// -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: -//// - Cos'è successo? Ora `CONTRIBUTING.md` è elencato sia dentro che fuori lo `stage`. Come è possibile? @@ -289,17 +180,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -//// -==== Short Status -//// ==== Status in formato breve -//// -While the `git status` output is pretty comprehensive, it's also quite wordy. -Git also has a short status flag so you can see your changes in a more compact way. -If you run `git status -s` or `git status --short` you get a far more simplified output from the command: -//// - Anche se l'output di `git status` è abbastanza completo, è anche piuttosto prolisso. Git però ha anche una opzione `short` di status così che si possono vedere le proprie modifiche in un modo più compatto. Se esegui `git status -s` o `git status --short` ottieni dal comando un output molto più semplificato: @@ -314,13 +196,6 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -//// -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. -There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. -So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. -The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. -//// - I nuovi file che non sono tracciati hanno un `??` accanto a loro, i nuovi file che sono stati aggiunti all'area di stage hanno una `A`, i file modificati hanno una `M` e così via. Nell'output ci sono due colonne -- la colonna a sinistra indica lo stato dell'area di stage e la colonna a destra indica lo stato dell'albero di lavoro. Così ad esempio, nel precedente output, il file `README` risulta modificato nella directory di lavoro ma non ancora inserito nell'area di stage, mentre il file `lib/simplegit.rb` é modificato ed inserito nell'area di stage. @@ -328,18 +203,8 @@ Il file `Rakefile` é stato modificato, inserito nell'area di stage e poi modifi [[_ignoring]] -//// -==== Ignoring Files -//// ==== Ignorare File -//// -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: -//// - Spesso hai dei file che non vuoi che Git aggiunga automaticamente e nemmeno che te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare.(((ignoring files))) @@ -352,28 +217,11 @@ $ cat .gitignore *~ ---- -//// -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. -The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. -//// - La prima riga dice a Git di ignorare qualsiasi file che finisce in ``.o'' or ``.a'' -- file di oggetti o archivi che possono essere il prodotto di una compilazione del tuo codice. La seconda riga dice a Git di ignorare tutti i file il cui nomefinisce con una tilde (`~`), che è usata da alcuni editor di testo come Emacs per marcare i file temporanei. Puoi anche includere le directory log, tmp o pid, documenti generati automaticamente e così via. Definire un file `.gitignore` per un tuo nuovo repository prima di iniziare è generalmente una buona idea, così eviti il rischio di registrare accidentalmente dei file che non vuoi nel tuo repository Git. -//// -The rules for the patterns you can put in the `.gitignore` file are as follows: - -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work, and will be applied recursively throughout the entire working tree. -* You can start patterns with a forward slash (`/`) to avoid recursivity. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). -//// - Queste sono le regole per i pattern che puoi usare in `.gitignore`: * Le righe vuote o che inizino con `#` vengono ignorate. @@ -382,20 +230,10 @@ Queste sono le regole per i pattern che puoi usare in `.gitignore`: * Puoi terminare i pattern con uno slash (`/`) per indicare una directory. * Puoi negare un pattern facendolo iniziare con un punto esclamativo (`!`). -//// -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. -//// - I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. L'asterisco `\*` corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto interrogativo `?` corrisponde ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno `[0-9]` corrispondono ad ogni carattere compreso tra di loro (in questo caso da 0 a 9). Puoi anche utilizzare due asterischi per avere la corrispondenza con le directory nidificate; `a/**/z` corrisponderà a `a/z`, `a/b/z`, `a/b/c/z`, e così via. -//// -Here is another example `.gitignore` file: -//// - Questo è un altro esempio di file `.gitignore`: [source] @@ -419,30 +257,11 @@ doc/*.txt doc/**/*.pdf ---- -//// -[TIP] -==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. -==== -//// - [TIP] ==== Se desideri un punto di partenza per i tuoi progetti, GitHub mantiene un elenco abbastanza completo di ottimi esempi di file `.gitignore` per decine di progetti e linguaggi all'URL https://github.com/github/gitignore[]. ==== -//// -[NOTE] -==== -In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. -However, it is also possible to have additional `.gitignore` files in subdirectories. -The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. -(The Linux kernel source repository has 206 `.gitignore` files.) - -It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. -==== -//// - [NOTE] ==== In un caso semplice, un repository potrebbe avere un singolo file `.gitignore` nella propria directory radice, che si applica ricorsivamente all'intero repository. @@ -455,21 +274,8 @@ Le regole di questi `.gitignore` nidificati si applicano soltanto ai file conten [[_git_diff_staged]] -//// -==== Viewing Your Staged and Unstaged Changes -//// ==== Mostra le modifiche dentro e fuori lo `stage` -//// -If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed -- the patch, as it were. - -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: -//// - Se `git status` è troppo vago per te -- vuoi sapere cos'è stato effettivamente modificato e non solo quali file -- puoi usare il comando `git diff`.(((git commands, diff))) Tratteremo più avanti `git diff` con maggior dettaglio, ma probabilmente lo userai molto spesso per rispondere a queste due domande: Cos'è che hai modificato ma non è ancora in `stage`? E cos'hai nello `stage` che non hai ancora registrato con commit? @@ -494,10 +300,6 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -//// -To see what you've changed but not yet staged, type `git diff` with no other arguments: -//// - Per vedere cosa hai modificato, ma non ancora inserito nell'area di `stage`, digita `git diff` senza altri argomenti: [source,console] @@ -519,14 +321,6 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -//// -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. - -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: -//// - Questo comando confronta cosa c'è nella tua directory di lavoro con quello che c'è nella tua area di `stage`. Il risultato mostra le tue modifiche che ancora non hai messo nello `stage`. @@ -545,19 +339,9 @@ index 0000000..03902a1 +My Project ---- -//// -It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. -If you've staged all of your changes, `git diff` will give you no output. -//// - È importante notare che `git diff` di per se non visualizza tutte le modifiche fatte dall'ultima commit, ma solo quelle che non sono ancora in `stage`. Se hai messo in `stage` tutte le tue modifiche, `git diff` non mostrerà nulla. -//// -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. -If our environment looks like this: -//// - Ecco un altro esempio, se metti in `stage` il file `CONTRIBUTING.md` e lo modifichi, puoi usare `git diff` per vedere quali modifiche al file sono in stage e i quali non ancora. Se il nostro ambiente assomiglia a questo: @@ -580,10 +364,6 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -//// -Now you can use `git diff` to see what is still unstaged: -//// - Allora puoi usare `git diff` per vedere cosa non è ancora in `stage` [source,console] @@ -600,10 +380,6 @@ index 643e24f..87f08c8 100644 +# test line ---- -//// -and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): -//// - e `git diff --cached` per vedere cos'è già in `stage` (`--staged` e `--cached` sono sinonimi) [source,console] @@ -625,17 +401,6 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -//// -[NOTE] -.Git Diff in an External Tool -==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. -There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. -If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). -Run `git difftool --tool-help` to see what is available on your system. -==== -//// - [NOTE] .Git Diff in uno Strumento Esterno ==== @@ -646,19 +411,8 @@ Esegui `git difftool --tool-help` per vedere cos'é disponibile sul tuo sistema. ==== [[_committing_changes]] -//// -==== Committing Your Changes -//// ==== Registra con commit le tue modifiche -//// -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) -//// - Ora che la tua area di stage è configurata come vuoi, puoi fare l'operazione di commit delle tue modifiche. Ricorda che tutto ciò che non è in `stage` -- qualsiasi file che hai creato o modificato per cui non hai fatto `git add` -- non sarà nell'operazione di commit. Rimarranno come file modificati sul tuo disco. @@ -670,13 +424,6 @@ Il modo più semplice per farlo è eseguire `git commit`:(((git commands, commit $ git commit ---- -//// -Doing so launches your editor of choice. -(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>).(((editor, changing default)))(((git commands, config))) - -The editor displays the following text (this example is a Vim screen): -//// - Facendolo lanci il tuo editor predefinito. (Questo è impostato nella tua shell con la variabile di ambiente `EDITOR` -- generalmente vim o emacs, sebbene tu possa configurarlo con qualsiasi altro editor, usando il comando `git config --global core.editor` come hai visto nel <>).(((editor, changing default)))(((git commands, config))) @@ -700,16 +447,6 @@ L'editor visualizzerà il testo (questo è un esempio della schermata di Vim): ".git/COMMIT_EDITMSG" 9L, 283C ---- -//// -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). - -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: -//// - Come vedi, il messaggio predefinito della commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. Puoi rimuovere questi commenti e inserire il tuo messaggio di commit, o puoi lasciarli così per aiutarti a ricordare cosa stai registrando con commit. (Per un promemoria ancora più esplicito puoi usare l'opzione `-v` con `git commit`. @@ -726,15 +463,6 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -//// -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. - -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. -//// - Hai creato la tua prima commit! Puoi vedere che la commit restituisce alcune informazioni su se stessa: su quale `branch` (ramo, ndt) hai fatto la commit (`master`), quale checksum SHA-1 ha la commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle righe aggiunte e rimosse con la commit. @@ -743,18 +471,9 @@ Qualsiasi cosa che non è nello `stage` rimarrà lì come modificata; puoi fare Ogni volta che fai una commit, stai salvando un'istantanea (`snapshot`) del tuo progetto che puoi ripristinare o confrontare in seguito. -//// -==== Skipping the Staging Area -//// ==== Saltare l'Area di Stage (((staging area, skipping))) -//// -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: -//// - Sebbene sia estremamente utile per amministrare le commit esattamente come vuoi, l'area di stage è molto più complessa di quanto tu possa necessitare nel lavoro normale. Se vuoi saltare l'area di `stage`, Git fornisce una semplice sccorciatoia. Aggiungendo l'opzione `-a` al comando `git commit`, Git, prima di eseguire la commit, mette automaticamente nello `stage` tutti i file che erano già tracciati, permettendoti di saltare la parte `git add`: @@ -776,30 +495,14 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -//// -Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. -That's because the `-a` flag includes all changed files. -This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. -//// - Nota come in questo caso non hai bisogno di eseguire `git add` per `CONTRIBUTING.md` prima della commit. Questo perchè l'opzione `-a` include tutti i file modificati. Questo è conveniente, ma attenzione: a volte questa opzione potrebbe causare l'inclusione di modifiche non volute. [[_removing_files]] -//// -==== Removing Files -//// ==== Rimuovere i File (((files, removing))) -//// -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. - -If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: -//// - Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente, rimuoverlo dall'area di `stage`) e quindi registrare con commit. Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato. @@ -820,10 +523,6 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -//// -Then, if you run `git rm`, it stages the file's removal: -//// - Se poi esegui `git rm`, la rimozione del file viene messa nello `stage`: @@ -840,17 +539,6 @@ Changes to be committed: deleted: PROJECTS.md ---- -//// -The next time you commit, the file will be gone and no longer tracked. -If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. - -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: -//// - La prossima volta che registrerai una commit, il file sparirà e non sarà più tracciato. Se avevi già modificato il file o lo avevi aggiunto all'area di stage, devi forzarne la rimozione con l'opzione `-f`. Questa è una misura di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati salvati in uno `snapshot` e che non potrebbero essere recuperati con Git. @@ -865,11 +553,6 @@ Per farlo usa l'opzione `--cached`: $ git rm --cached README ---- -//// -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as: -//// - Puoi passare file, directory o pattern glob di file al comando `git rm`. Questo significa che puoi fare: @@ -878,13 +561,6 @@ Questo significa che puoi fare: $ git rm log/\*.log ---- -//// -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: -//// - Nota la barra inversa (`\`) prima di `*`. Questo è necessario perché Git ha un'espansione propria dei nomi di file oltre a quella della tua shell. Questo comando rimuove tutti i file che hanno l'estensione `.log` nella directory `log/`. @@ -895,28 +571,12 @@ Oppure, puoi fare qualcosa di questo tipo: $ git rm \*~ ---- -//// -This command removes all files whose names end with a `~`. -//// - Questo comando rimuove tutti i file il cui nome termina con una `~`. [[_git_mv]] -//// -==== Moving Files -//// ==== Spostare i File (((files, moving))) -//// -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. - -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like: -//// - A differenza di altri sistemi VCS, Git non traccia esplicitamente gli spostamenti dei file. Se rinomini un file in Git, nessun metadato viene salvato per dirgli che lo hai rinominato. Tuttavia, Git è abbastanza intelligente da capirlo dopo che l'hai fatto -- più in la ci occuperemo di rilevare il movimento dei file. @@ -929,11 +589,6 @@ Se vuoi rinominare un file in Git puoi eseguire qualcosa come: $ git mv file_from file_to ---- -//// -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: -//// - e funziona bene. Se, infatti, lanci un comando del genere e controlli lo stato, vedrai che Git considera il file rinominato: @@ -949,10 +604,6 @@ Changes to be committed: renamed: README.md -> README ---- -//// -However, this is equivalent to running something like this: -//// - Comunque, questo è equivalente ad eseguire qualcosa come: [source,console] @@ -962,12 +613,6 @@ $ git rm README.md $ git add README ---- -//// -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `git mv` is one command instead of three -- it's a convenience function. -More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. -//// - Git capisce che implicitamente stai rinominando il file, così che non c'è differenza tra rinominare un file in questo modo o con il comando `mv`. L'unica differenza reale è che `mv` è un solo comando invece di tre -- è un questione di convenienza. Ciò che più conta è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit. From b16bca862ea138de953aba0992bcc487a455cd00 Mon Sep 17 00:00:00 2001 From: Fedro Date: Fri, 30 Aug 2019 00:08:04 +0200 Subject: [PATCH 31/44] avanzamento nella traduzione di viewiong --- .../sections/viewing-history.asc | 87 +++++++++++++------ 1 file changed, 60 insertions(+), 27 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 1ed1c34..05e6b9c 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -243,22 +243,23 @@ a11bef0 - Scott Chacon, 6 years ago : first commit |================================ | Opzione | Descrizione dell'Output | `%H` | Hash della commit -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author email -| `%ad` | Author date (format respects the --date=option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject +| `%h` | Hash della commit abbreviato +| `%T` | Hash dell'albero +| `%t` | Hash dell'albero abbreviato +| `%P` | Hash del genitore +| `%p` | Hash del genitore abbreviato +| `%an` | Nome dell'autore +| `%ae` | e-mail dell'autore +| `%ad` | Data di commit dell'autore (il formato rispetta l'opzione --date=) +| `%ar` | Data relativa di commit dell'autore +| `%cn` | Nome di chi ha fatto la commit (`committer`, in inglese) +| `%ce` | e-mail di chi ha fatto la commit +| `%cd` | Data della commit +| `%cr` | Data relativa della commit +| `%s` | Oggetto |================================ +//// You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer. @@ -266,6 +267,13 @@ We'll cover this distinction a bit more in <> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +//// + +Questo tipo di output diventerà più interessante quando ci inoltreremo nel _brancing_ e nel _merging_ nel prossimo capitolo. + +Queste sono solo alcune semplici opzioni per la formattazione dell'output di `git log` -- ce ne sono altre. +<> elenca le opzioni che abbiamo visto prima, come anche altre opzioni comunemente usate che possono essere utili per cambiare l'output del comando log. [[log_options]] -.Common options to `git log` +.Opzioni comuni di `git log` [cols="1,4",options="header"] |================================ -| Option | Description -| `-p` | Show the patch introduced with each commit. -| `--stat` | Show statistics for files modified in each commit. -| `--shortstat` | Display only the changed/insertions/deletions line from the --stat command. -| `--name-only` | Show the list of files modified after the commit information. -| `--name-status` | Show the list of files affected with added/modified/deleted information as well. -| `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40. -| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. -| `--graph` | Display an ASCII graph of the branch and merge history beside the log output. -| `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). -| `--oneline` | Shorthand for `--pretty=oneline --abbrev-commit` used together. +| Opzione | Descrizione +| `-p` | Mostra la modifica introdotta con ogni commit. +| `--stat` | Mostra le statistiche per i file modificati in ogni commit. +| `--shortstat` | Mostra solo le righe cambiate/aggiunte/rimosse del comando --stat. +| `--name-only` | Mostra l'elenco dei file modificati dopo le informazione della commit. +| `--name-status` | Mostra l'elenco dei file con le informazioni aggiunte/modifiche/eliminate. +| `--abbrev-commit` | Mostra solo i primi caratteri del codice SHA-1 invece di tutti i 40. +| `--relative-date` | Mostra la data in un formato relativo (per esempio, "2 week ago", "2 settimane fa") invece di usare il formato completo della data. +| `--graph` | Mostra un grafico ASCII della cronologia delle diramazioni e delle unioni insieme all'output del log. +| `--pretty` | Mostra le commit in un formato alternativo. L'opzione include oneline, short, full, fuller, e format (quando specifichi un tuo formato). +| `--oneline` | Abbreviazione per `--pretty=oneline --abbrev-commit` usate assieme. |================================ -==== Limiting Log Output +==== Limitare l'Output del Log +//// In addition to output-formatting options, `git log` takes a number of useful limiting options; that is, options that let you show only a subset of commits. You've seen one such option already -- the `-2` option, which displays only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. @@ -313,16 +329,33 @@ In reality, you're unlikely to use that often, because Git by default pipes all However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks: +//// + +Oltre alle opzioni per la formattazione dell'output, `git log` accetta una serie di utili opzioni restrittive, ovvero opzioni che ti permettono di vedere solo alcune commit. +Abbiamo già visto una opzione del genere, l'opzione `-2`, che visualizza solamente le ultime due commit. +Infatti, puoi usare `-`, dove `n` è un intero, per vedere le ultime `n` commit. +In realtà non la userai spesso, perché Git accoda tutti gli output paginandoli, così vedrai solamente una pagina alla volta. + +Le opzioni temporali come `--since` e `--until` sono invece molto utili. +Questo comando, per esempio, prende la lista delle commit fatte nelle ultime due settimane: [source,console] ---- $ git log --since=2.weeks ---- +//// This command works with lots of formats -- you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. +//// + +Questo comando funziona con molti formati -- puoi specificare una data `"2008-01-15"` o una data relativa come `"2 years 1 day 3 minutes ago"`. + +Puoi inoltre filtrare l'elenco delle commit che corrispondono a dei criteri di ricerca. +L'opzione `--author` ti permette di filtrare per uno specifico autore e l'opzione `--grep` ti permette di cercare delle parole chiave nei messaggi delle commit. +(Nota che specifichi entrambe le opzioni il comando cercherà le commit che corrispondano a tutte le opzioni specificate.) [NOTE] ==== From 8254fd1e36102d503e7029504a679d076ac16835 Mon Sep 17 00:00:00 2001 From: Fedro Date: Sat, 31 Aug 2019 00:01:14 +0200 Subject: [PATCH 32/44] completata la traduzione della sezione viewing --- .../sections/viewing-history.asc | 159 +++--------------- 1 file changed, 21 insertions(+), 138 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 05e6b9c..5ad7a3f 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,17 +1,6 @@ [[_viewing_history]] -//// -=== Viewing the Commit History -//// === Vedere la Cronologia delle Commit -//// -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. - -These examples use a very simple project called ``simplegit''. -To get the project, run -//// - Dopo che avrai creato un po' di commit, o se hai clonato un repository che già ha la sua cronologia di commit, vorrai probabilmente guardare cos'è successo nel passato. Lo strumento essenziale e quello più potente per farlo è il comando `git log`. @@ -23,10 +12,6 @@ Per ottenere il progetto, esegui $ git clone https://github.com/schacon/simplegit-progit ---- -//// -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) -//// - Quando esegui `git log` in questo progetto, dovresti avere un output che assomiglia a questo:(((git commands, log))) [source,console] @@ -51,17 +36,6 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -//// -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and email, the date written, and the commit message. - -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. - -One of the more helpful options is `-p` or `--patch`, which shows the difference (the _patch_ output) introduced in each commit. -You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries. -//// - In modo predefinito, senza argomenti, `git log` mostra le commit fatte nel repository in ordine cronologico inverso, in questo modo la commit più recente è la prima ad apparire. Come vedi, questo comando elenca ogni commit con il suo codice SHA-1, il nome e l'email dell'autore, la data di salvataggio e il messaggio della commit. @@ -115,13 +89,6 @@ index a0a60ae..47c6340 100644 -end ---- -//// -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: -//// - Quest'opzione mostra le stessi informazioni ma ciascun elemento è seguito dalle differenze. Questo è molto utile per revisionare il codice o per dare un'occhiata veloce a cosa è successo in una serie di commit che un collaboratore ha aggiunto. @@ -161,22 +128,9 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -//// -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. -//// - Come puoi vedere, l'opzione `--stat` visualizza sotto ogni commit la lista dei file modificati, quanti file sono stati modificati, e quante righe in questi file sono state aggiunte e rimosse. Alla fine aggiunge anche un resoconto delle informazioni. -//// -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: -//// - Un'altra opzione veramente utile è `--pretty`. Questa opzione modifica gli output di log rispetto a quella predefinita. Alcune opzioni predefinite sono pronte all'uso. @@ -191,11 +145,6 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -//// -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing -- because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) -//// - L'opzione più interessante è `format`, che ti permette di specificare la formattazione dell'output di log. Questa è estremamente utile quando stai generando un output che sarà sottoposto ad analisi automatica -- perché specificando esplicitamente il formato, sai che non cambierà con gli aggiornamenti di Git:(((log formatting))) @@ -207,36 +156,8 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -//// -<> lists some of the more useful options that `format` takes. -//// - <> elenca alcune delle opzioni maggiormente utili che `format` accetta. -//// -[[pretty_format]] -.Useful options for `git log --pretty=format` -[cols="1,4",options="header"] -|================================ -| Option | Description of Output -| `%H` | Commit hash -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author email -| `%ad` | Author date (format respects the --date=option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject -|================================ -//// - [[pretty_format]] .Opzioni utili per `git log --pretty=format` [cols="1,4",options="header"] @@ -259,16 +180,6 @@ a11bef0 - Scott Chacon, 6 years ago : first commit | `%s` | Oggetto |================================ -//// -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <>. - -The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: -//// - Potresti essere sorpreso dalla differenza tra _autore_ e _committer_ (chi ha eseguito la commit). L'autore è la persona che ha scritto il testo, mentre il committer è l'ultima persona che ha applicato il testo. Così, se invii una modifica a un progetto ed uno dei membri principali del progetto la applica, ne avranno entrambi il riconoscimento — tu come l'autore ed il membro del progetto come chi l'ha committata. Vedremo meglio questa distinzione nel *Capitolo 5*. @@ -290,13 +201,6 @@ $ git log --pretty=format:"%h %s" --graph * 11d191e Merge branch 'defunkt' into local ---- -//// -This type of output will become more interesting as we go through branching and merging in the next chapter. - -Those are only some simple output-formatting options to `git log` -- there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. -//// - Questo tipo di output diventerà più interessante quando ci inoltreremo nel _brancing_ e nel _merging_ nel prossimo capitolo. Queste sono solo alcune semplici opzioni per la formattazione dell'output di `git log` -- ce ne sono altre. @@ -321,16 +225,6 @@ Queste sono solo alcune semplici opzioni per la formattazione dell'output di `gi ==== Limitare l'Output del Log -//// -In addition to output-formatting options, `git log` takes a number of useful limiting options; that is, options that let you show only a subset of commits. -You've seen one such option already -- the `-2` option, which displays only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. - -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: -//// - Oltre alle opzioni per la formattazione dell'output, `git log` accetta una serie di utili opzioni restrittive, ovvero opzioni che ti permettono di vedere solo alcune commit. Abbiamo già visto una opzione del genere, l'opzione `-2`, che visualizza solamente le ultime due commit. Infatti, puoi usare `-`, dove `n` è un intero, per vedere le ultime `n` commit. @@ -344,56 +238,45 @@ Questo comando, per esempio, prende la lista delle commit fatte nelle ultime due $ git log --since=2.weeks ---- -//// -This command works with lots of formats -- you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. - -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. -//// - Questo comando funziona con molti formati -- puoi specificare una data `"2008-01-15"` o una data relativa come `"2 years 1 day 3 minutes ago"`. Puoi inoltre filtrare l'elenco delle commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare per uno specifico autore e l'opzione `--grep` ti permette di cercare delle parole chiave nei messaggi delle commit. -(Nota che specifichi entrambe le opzioni il comando cercherà le commit che corrispondano a tutte le opzioni specificate.) [NOTE] ==== -You can specify more than one instance of both the `--author` and `--grep` search criteria, which -will limit the commit output to commits that match _any_ of the `--author` patterns and _any_ -of the `--grep` patterns; however, adding the `--all-match` option further limits the output to -just those commits that match _all_ `--grep` patterns. +Puoi specificare più di una istanza di entrambi i criteri di ricerca `--author` e `--grep`, che limiteranno l'output della commit alle registrazioni che corrispondono ad _ognuno_ degli schemi `--author` ed ad _ognuno_ degli schemi `--grep`; comunque, aggiungendo l'ulteriore opzione `--all-match` si limita l'output solo a quelle commit che corrispondono a _tutti_ gli schemi `--grep`. ==== -Another really helpful filter is the `-S` option (colloquially referred to as Git's ``pickaxe'' option), which takes a string and shows only those commits that changed the number of occurrences of that string. -For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +Un altro filtro estremamente utile è l'opzione `-S` (a cui confidenzialmente ci si riferisce come l'opzione ``picozza'' di Git),che accetta una stringa e mostra solo quelle commit in cui è cambiato il numero di occorrenze di tale stringa. +Ad esempio, se cerchi di trovare l'ultima commit che aggiunge o rimuove il riferimento ad una funzione specifica, potresti richiamare: [source,console] ---- $ git log -S function_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +L'ultima opzione veramente utile da passare a `git log` come filtro è il percorso. +Se specifichi il nome di una directory o di un file, puoi limitare l'output del log alle sole commit che introducono modifiche a quei file. +Questa è sempre l'ultima opzione e generalmente è preceduta dal doppio meno (`--`) per separare i percorsi dalle opzioni. -In <> we'll list these and a few other common options for your reference. +Nella <> vediamo una lista di riferimento di queste e di altre opzioni comuni. [[limit_options]] -.Options to limit the output of `git log` +.Opzioni per limitare l'output di `git log` [cols="2,4",options="header"] |================================ -| Option | Description -| `-` | Show only the last n commits -| `--since`, `--after` | Limit the commits to those made after the specified date. -| `--until`, `--before` | Limit the commits to those made before the specified date. -| `--author` | Only show commits in which the author entry matches the specified string. -| `--committer` | Only show commits in which the committer entry matches the specified string. -| `--grep` | Only show commits with a commit message containing the string -| `-S` | Only show commits adding or removing code matching the string +| Opzione | Descrizione +| `-` | Mostra solo le ultime n commit +| `--since`, `--after` | Limita le commit a quelle create dopo la data specificata. +| `--until`, `--before` | Limita le commit a quelle create prima della data specificata. +| `--author` | Mostra solo le commit in cui la voce autore corrisponde alla stringa specificata. +| `--committer` | Mostra solo le commit in cui la voce committer corrisponde alla stringa specificata. +| `--grep` | Mostra solo le commit il cui messaggio contiene la stringa +| `-S` | Mostra solo le commit con aggiunte o rimozioni di codice in cui la stringa trova corrispondenza |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering))) +Ad esempio, se vuoi vedere quali commit, che modificano i file di test nella cronologia del codice sorgente di Git, sono state registrate da Junio Hamano nel mese di Ottobre 2008 e non sono commit di fusione (merge), puoi eseguire qualcosa come questo: [source,console] ---- @@ -407,11 +290,11 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Delle quasi 40.000 commit, presenti nella cronologia del codice sorgente di Git, questo comando mostra le 6 che corrispondono a tali criteri. [TIP] -.Preventing the display of merge commits +.Evitare di visualizzare le commit di fusione (merge) ==== -Depending on the workflow used in your repository, it's possible that a sizable percentage of the commits in your log history are just merge commits, which typically aren't very informative. -To prevent the display of merge commits cluttering up your log history, simply add the log option `--no-merges`. +Dipende dal flusso di lavoro utilizzato nel tuo repository, ma è possibile che una considerevole percentuale delle commit nella cronologia di log siano soltanto commit di fusione, che in genere non sono molto istruttive. +Per evitare di visualizzare un ammasso di commit di fusione nella tua cronologia di log, aggiungi semplicemente l'opzione di log `--no-merges`. ==== From a6ab5fa3a877251450e1bca96d850de5d9bcb841 Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 1 Sep 2019 21:51:19 +0200 Subject: [PATCH 33/44] iniziata traduzione di undoing --- book/02-git-basics/sections/undoing.asc | 68 ++++++++++++++++++++----- 1 file changed, 55 insertions(+), 13 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 01f018d..df813eb 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,19 +1,30 @@ [[_undoing]] -=== Undoing Things +=== Annullare qualcosa +//// At any stage, you may want to undo something. Here, we'll review a few basic tools for undoing changes that you've made. Be careful, because you can't always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to try that commit again, you can run commit with the `--amend` option: +If you want to redo that commit, make the additional changes you forgot, stage them, and commit again using the `--amend` option: +//// + +In qualsiasi momento puoi voler annullare qualcosa. +Rivedremo alcuni strumenti basilari per annullare le modifiche fatte. +Attenzione però, perché non sempre puoi ripristinare ciò che annulli. +Questa è una delle aree di Git dove puoi perdere del lavoro svolto se commetti un errore. + +Uno degli annullamenti più comuni si verifica quando registri una commit troppo presto e magari dimentichi di aggiungere qualche file, o sbagli qualcosa nel messaggio di commit. +Se vuoi rifare questa commit, esegui le ulteriori modifiche che hai dimenticato, mettile nell'area di stage e esegui di nuovo la commit utilizzando l'opzione `--amend`: [source,console] ---- $ git commit --amend ---- +//// This command takes your staging area and uses it for the commit. If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. @@ -21,6 +32,15 @@ The same commit-message editor fires up, but it already contains the message of You can edit the message the same as always, but it overwrites your previous commit. As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +//// + +Questo comando usa la tua area di `stage` per la commit. +Se non hai fatto modifiche dalla tua ultima commit (per esempio, esegui questo comando subito dopo la tua commit precedente), allora il tuo snapshot sarà identico e potrai cambiare il tuo messaggio di commit. + +Verrà lanciata la stessa applicazione per scrivere il messaggio della commit, ma conterrà già il messaggio della commit precedente. +Puoi modificare il messaggio normalmente, ma questo sovrascriverà la commit precedente. + +Per esempio, se fai una commit e realizzi di non aver messo nello `stage` le modifiche a un file e vuoi aggiungerlo a questa commit, puoi fare così: [source,console] ---- @@ -29,12 +49,31 @@ $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit – the second commit replaces the results of the first. +//// +You end up with a single commit -- the second commit replaces the results of the first. + +[NOTE] +==== +It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place. +Effectively, it's as if the previous commit never happened, and it won't show up in your repository history. + +The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''. +==== +//// + +Ti ritroverai con una sola commit: la seconda sovrascrive la prima. + +[NOTE] +==== +É importante comprendere che quando si corregge la propria ultima commit, It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place. +Effectively, it's as if the previous commit never happened, and it won't show up in your repository history. -[[r_unstaging]] +The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''. +==== +[[_unstaging]] ==== Unstaging a Staged File -The next two sections demonstrate how to wrangle your staging area and working directory changes. +The next two sections demonstrate how to work with your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. How can you unstage one of the two? @@ -42,7 +81,7 @@ The `git status` command reminds you: [source,console] ---- -$ git add . +$ git add * $ git status On branch master Changes to be committed: @@ -79,15 +118,17 @@ The `CONTRIBUTING.md` file is modified but once again unstaged. [NOTE] ===== -While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area. +It's true that `git reset` can be a dangerous command, especially if you provide the `--hard` flag. +However, in the scenario described above, the file in your working directory is not touched, so it's relatively safe. ===== -For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <>. +For now this magic invocation is all you need to know about the `git reset` command. +We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <>. ==== Unmodifying a Modified File What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it – revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? +How can you easily unmodify it -- revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this: @@ -119,12 +160,13 @@ You can see that the changes have been reverted. [IMPORTANT] ===== -It's important to understand that `git checkout -- [file]` is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. -Don't ever use this command unless you absolutely know that you don't want the file. +It's important to understand that `git checkout -- ` is a dangerous command. +Any local changes you made to that file are gone -- Git just replaced that file with the most recently-committed version. +Don't ever use this command unless you absolutely know that you don't want those unsaved local changes. ===== If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <>; these are generally better ways to go. -Remember, anything that is __committed__ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <> for data recovery). +Remember, anything that is _committed_ in Git can almost always be recovered. +Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <> for data recovery). However, anything you lose that was never committed is likely never to be seen again. From 8d57b1ab3e9dfe16b3b1050ddff8fd41385203ce Mon Sep 17 00:00:00 2001 From: Fedro Date: Thu, 5 Sep 2019 23:52:59 +0200 Subject: [PATCH 34/44] tradotta una nota della versione nuova --- book/02-git-basics/sections/undoing.asc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index df813eb..edded72 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -65,11 +65,13 @@ Ti ritroverai con una sola commit: la seconda sovrascrive la prima. [NOTE] ==== -É importante comprendere che quando si corregge la propria ultima commit, It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place. -Effectively, it's as if the previous commit never happened, and it won't show up in your repository history. +É importante comprendere che quando si corregge la propria ultima commit, non è tanto una semplice correzione quanto piuttosto una completa _sostituzione_ con una nuova commit migliorata che spinge via la vecchia commit e mette al suo posto la nuova commit. +In pratica è come se la commit precedente non ci fosse mai stata e quindi non apparirà nella cronologia del tuo repository. -The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''. +L'ovvio significato della correzione delle commit è quello di fare miglioramenti minori della tua ultima commit, senza intasare la cronologia del tuo repository con messaggi di commit del tipo ``Oops, dimenticato di aggiungere un file'' oppure ``Accidenti, corretto un refuso nell'ultima commit''. ==== + + [[_unstaging]] ==== Unstaging a Staged File From 1678dbec9f3fdeda5fd6881663057b7e544bba34 Mon Sep 17 00:00:00 2001 From: Fedro Date: Fri, 6 Sep 2019 01:32:21 +0200 Subject: [PATCH 35/44] completata traduzione della sezione undoing --- book/02-git-basics/sections/undoing.asc | 92 +++++++++---------------- 1 file changed, 31 insertions(+), 61 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index edded72..d2edf5a 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,16 +1,6 @@ [[_undoing]] === Annullare qualcosa -//// -At any stage, you may want to undo something. -Here, we'll review a few basic tools for undoing changes that you've made. -Be careful, because you can't always undo some of these undos. -This is one of the few areas in Git where you may lose some work if you do it wrong. - -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to redo that commit, make the additional changes you forgot, stage them, and commit again using the `--amend` option: -//// - In qualsiasi momento puoi voler annullare qualcosa. Rivedremo alcuni strumenti basilari per annullare le modifiche fatte. Attenzione però, perché non sempre puoi ripristinare ciò che annulli. @@ -24,16 +14,6 @@ Se vuoi rifare questa commit, esegui le ulteriori modifiche che hai dimenticato, $ git commit --amend ---- -//// -This command takes your staging area and uses it for the commit. -If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. - -The same commit-message editor fires up, but it already contains the message of your previous commit. -You can edit the message the same as always, but it overwrites your previous commit. - -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: -//// - Questo comando usa la tua area di `stage` per la commit. Se non hai fatto modifiche dalla tua ultima commit (per esempio, esegui questo comando subito dopo la tua commit precedente), allora il tuo snapshot sarà identico e potrai cambiare il tuo messaggio di commit. @@ -49,18 +29,6 @@ $ git add forgotten_file $ git commit --amend ---- -//// -You end up with a single commit -- the second commit replaces the results of the first. - -[NOTE] -==== -It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place. -Effectively, it's as if the previous commit never happened, and it won't show up in your repository history. - -The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''. -==== -//// - Ti ritroverai con una sola commit: la seconda sovrascrive la prima. [NOTE] @@ -73,13 +41,13 @@ L'ovvio significato della correzione delle commit è quello di fare migliorament [[_unstaging]] -==== Unstaging a Staged File +==== Rimuovere un file dall'area di `stage` -The next two sections demonstrate how to work with your staging area and working directory changes. -The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. -For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. -How can you unstage one of the two? -The `git status` command reminds you: +Le prossime due sezioni mostrano come lavorare con le modifiche della tua area di stage e della directory di lavoro. +La parte divertente è che il comando che usi per determinare lo stato di queste due aree ti ricorda come annullare le modifiche alle stesse. +Per esempio, supponiamo che hai modificato due file e vuoi registrarli (commit) come modifiche separate, ma accidentalmente digiti `git add *` e li metti entrambi in `stage`. +Come puoi rimuoverne uno? +Il comando `git status` ti ricorda: [source,console] ---- @@ -93,8 +61,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -Right below the ``Changes to be committed'' text, it says use `git reset HEAD ...` to unstage. -So, let's use that advice to unstage the `CONTRIBUTING.md` file: +Il testo sotto ``Changes to be committed'' ti dice di usare `git reset HEAD ...` per rimuovere dallo `stage`. +Usa quindi questo consiglio per rimuovere `CONTRIBUTING.md`: [source,console] ---- @@ -115,24 +83,26 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -The command is a bit strange, but it works. -The `CONTRIBUTING.md` file is modified but once again unstaged. +Il comando è un po' strano, ma funziona. +Il file `CONTRIBUTING.md` ora è modificato ma non più nello `stage`. [NOTE] ===== -It's true that `git reset` can be a dangerous command, especially if you provide the `--hard` flag. -However, in the scenario described above, the file in your working directory is not touched, so it's relatively safe. +É vero che `git reset` può essere un comando pericoloso, specialmente se si usa l'opzione `--hard`. +Ad ogni modo, nello scenario sopra descritto, il file nella tua directory di lavoro non viene toccato e quindi è una situazione relativamente sicura. ===== -For now this magic invocation is all you need to know about the `git reset` command. -We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <>. +Per adesso questa invocazione magica è tutto quello che ti è necessario conoscere sul comando `git reset`. +Andremo più nel dettaglio su cosa esegue `reset` e su come padroneggiarlo per fare cose realmente interessanti in <>. + + +==== Annullare le modifiche a un file -==== Unmodifying a Modified File +Come fare se ti rendi conto che non vuoi più mantenere le modifiche di `CONTRIBUTING.md`? +Come puoi annullarle facilmente -- ritornare a come era prima dell'ultima commit (o al clone iniziale, o comunque lo avevi nella tua directory di lavoro)? +Fortunatamente `git status` ti dice come farlo. +Nell'ultimo output di esempio, l'area dei file modificati appare così: -What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it -- revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? -Luckily, `git status` tells you how to do that, too. -In the last example output, the unstaged area looks like this: [source,console] ---- @@ -143,8 +113,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -It tells you pretty explicitly how to discard the changes you've made. -Let's do what it says: +Ti dice abbastanza chiaramente come annullare le modifiche che hai fatto. +Vediamo cosa dice: [source,console] ---- @@ -158,17 +128,17 @@ Changes to be committed: ---- -You can see that the changes have been reverted. +Puoi vedere come le modifiche siano state annullate. [IMPORTANT] ===== -It's important to understand that `git checkout -- ` is a dangerous command. -Any local changes you made to that file are gone -- Git just replaced that file with the most recently-committed version. -Don't ever use this command unless you absolutely know that you don't want those unsaved local changes. +É importante capire che `git checkout -- ` è un comando pericoloso. +Tutte le modifiche locali fatte al file sono sparite -- Git ha praticamente rimpiazzato il file con la versione della commit più recente. +Non usare mai questo comando a meno che tu non sia assolutamente certo di non volere quei cambiamenti locali non salvati. ===== -If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <>; these are generally better ways to go. +Se desideri mantenere le modifiche apportate a questo file ma tuttavia hai bisogno per adesso di toglierlo di torno, vedremo i `ripostigli` (*stash*) e le diramazioni (*branch*) in <>, che generalmente sono le strade migliori da seguire. -Remember, anything that is _committed_ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <> for data recovery). -However, anything you lose that was never committed is likely never to be seen again. +Ricorda: qualsiasi cosa che sia stata _registrata in una commit_ in Git può quasi sempre essere recuperata. +Tutte le commit che erano su diramazioni che sono state cancellate o le commit sovrascritte con una commit `--amend` possono essere recuperate (vedi il <> per il recupero dei dati). +Ma qualsiasi cosa che perdi, che non sia stata mai registrata su commit, non la vedrai mai più. From 2bcee079170c79f0a7812653be374eade788350b Mon Sep 17 00:00:00 2001 From: Fedro Date: Fri, 6 Sep 2019 17:40:25 +0200 Subject: [PATCH 36/44] sostituito remotes con l'originale inglese --- book/02-git-basics/sections/remotes.asc | 56 +++++++++++++++---------- 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 442145b..a150fbf 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,4 +1,4 @@ -[[r_remote_repos]] +[[_remote_repos]] === Working with Remotes To be able to collaborate on any Git project, you need to know how to manage your remote repositories. @@ -8,11 +8,19 @@ Collaborating with others involves managing these remote repositories and pushin Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we'll cover some of these remote-management skills. +[NOTE] +.Remote repositories can be on your local machine. +==== +It is entirely possible that you can be working with a ``remote'' repository that is, in fact, on the same host you are. +The word ``remote'' does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. +Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote. +==== + ==== Showing Your Remotes To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from: +If you've cloned your repository, you should at least see `origin` -- that is the default name Git gives to the server you cloned from: [source,console] ---- @@ -56,14 +64,16 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here. +This means we can pull contributions from any of these users pretty easily. +We may additionally have permission to push to one or more of these, though we can't tell that here. -Notice that these remotes use a variety of protocols; we'll cover more about this in <>. +Notice that these remotes use a variety of protocols; we'll cover more about this in <>. ==== Adding Remote Repositories -I've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add [shortname] [url]`: +We've mentioned and given some demonstrations of how the `git clone` command implicitly adds the `origin` remote for you. +Here's how to add a new remote explicitly.(((git commands, remote))) +To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: [source,console] ---- @@ -92,17 +102,17 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. +Paul's master branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. (We'll go over what branches are and how to use them in much more detail in <>.) -[[r_fetching_and_pulling]] +[[_fetching_and_pulling]] ==== Fetching and Pulling from Your Remotes As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) [source,console] ---- -$ git fetch [remote-name] +$ git fetch ---- The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. @@ -110,18 +120,18 @@ After you do this, you should have references to all the branches from that remo If you clone a repository, the command automatically adds that remote repository under the name ``origin''. So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. +It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready. -If you have a branch set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) +If your current branch is set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. -[[r_pushing_remotes]] +[[_pushing_remotes]] ==== Pushing to Your Remotes When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push [remote-name] [branch-name]`.(((git commands, push))) +The command for this is simple: `git push `.(((git commands, push))) If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: [source,console] @@ -131,13 +141,13 @@ $ git push origin master This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push. +You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push. See <> for more detailed information on how to push to remote servers. -[[r_inspecting_remote]] +[[_inspecting_remote]] ==== Inspecting a Remote -If you want to see more information about a particular remote, you can use the `git remote show [remote-name]` command.(((git commands, remote))) +If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) If you run this command with a particular shortname, such as `origin`, you get something like this: [source,console] @@ -188,11 +198,11 @@ $ git remote show origin ---- This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`. +It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`. -==== Removing and Renaming Remotes +==== Renaming and Removing Remotes -If you want to rename a reference you can run `git remote rename` to change a remote's shortname.(((git commands, remote))) +You can run `git remote rename` to change a remote's shortname.(((git commands, remote))) For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: [source,console] @@ -203,14 +213,16 @@ origin paul ---- -It's worth mentioning that this changes your remote branch names, too. +It's worth mentioning that this changes all your remote-tracking branch names, too. What used to be referenced at `pb/master` is now at `paul/master`. -If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can use `git remote rm`: +If you want to remove a remote for some reason -- you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore -- you can either use `git remote remove` or `git remote rm`: [source,console] ---- -$ git remote rm paul +$ git remote remove paul $ git remote origin ---- + +Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted. From c9e446cbc4b4d955834b4e402bfc92e23c16829a Mon Sep 17 00:00:00 2001 From: Fedro Date: Sun, 8 Sep 2019 19:37:45 +0200 Subject: [PATCH 37/44] progredito nella traduzione della sezione remotes --- book/02-git-basics/sections/remotes.asc | 86 +++++++++++++++++++++++-- 1 file changed, 81 insertions(+), 5 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index a150fbf..0711491 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,4 +1,5 @@ [[_remote_repos]] +//// === Working with Remotes To be able to collaborate on any Git project, you need to know how to manage your remote repositories. @@ -15,12 +16,36 @@ It is entirely possible that you can be working with a ``remote'' repository tha The word ``remote'' does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote. ==== +//// +=== Lavorare con i Repository Remoti -==== Showing Your Remotes +Per poter collaborare con un qualsiasi progetto Git, devi sapere come amministrare i tuoi repository remoti. +I repository remoti sono versioni dei progetti ospitate da qualche parte su Internet o sulla rete locale. +Puoi averne molti e normalmente avrai un accesso in sola lettura o anche in scrittura. +Collaborare con altri implica di sapere amministrare questi repository remoti, inviarne e prelevarne dati per condividere il lavoro. +Amministrare i repository remoti significa sapere come aggiungerli, rimuovere quelli che non sono più validi, amministrare varie diramazioni remote e decidere quali tracciare e quali no, e altro ancora. +Di seguito tratteremo alcune conoscenze necessarie per farlo. +[NOTE] +.I repository remoti possono essere in locale sul tuo computer. +==== +É del tutto possibile che tu possa lavorare con un repository ``remoto'' che in realtà è sullo stesso computer dove sei tu. +La parola ``remoto'' non implica necessariamente che il repository sia da qualche altra parte sulla rete o su Internet, ma solo che è altrove. +Lavorare con un repository remoto del genere comporta comunque tutte le operazioni standard di invio, estrazione e recupero come con qualsiasi altro repository remoto. +==== + + +==== Vedere i Propri Server Remoti + +//// To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) It lists the shortnames of each remote handle you've specified. If you've cloned your repository, you should at least see `origin` -- that is the default name Git gives to the server you cloned from: +//// + +Per vedere i server remoti che hai configurato, puoi eseguire il comando `git remote`.(((git commands, remote))) +Questo elenca i nomi brevi di ogni nodo remoto che hai configurato. +Se hai clonato il tuo repository, dovresti vedere almeno `origin` -- che è il nome predefinito che Git da al server da cui cloni: [source,console] ---- @@ -36,7 +61,11 @@ $ git remote origin ---- +//// You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: +//// + +Puoi anche aggiungere `-v`, che mostra anche l'URL che Git ha associato a quel nome breve per utilizzarlo quando si legge o si scrive su questo repository remoto: [source,console] ---- @@ -45,8 +74,13 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- +//// If you have more than one remote, the command lists them all. For example, a repository with multiple remotes for working with several collaborators might look something like this. +//// + +Se hai più di un server remoto, il comando li elenca tutti. +Per esempio un repository, con multipli server remoti per lavorare con diversi collaboratori, appare così: [source,console] ---- @@ -64,16 +98,34 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- +//// This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here. +//// +Questo significa che posso prendere facilmente i contributi da qualunque di questi utenti. +Potremmo inoltre avere il permesso di inviare dati (push) ad uno o più di questi, anche se non ne possiamo parlare qui. + +//// Notice that these remotes use a variety of protocols; we'll cover more about this in <>. +//// + +Nota che questi server remoti utilizzano una molteplicità di protocolli; al riguardo ne tratteremo di più in <>. +//// ==== Adding Remote Repositories +//// +==== Aggiungere un Repository Remoto +//// We've mentioned and given some demonstrations of how the `git clone` command implicitly adds the `origin` remote for you. Here's how to add a new remote explicitly.(((git commands, remote))) To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: +//// + +Abbiamo citato e dato alcune dimostrazioni di come il comando `git clone` aggiunga implicitamente il repository remoto `origin`. +Ecco qui come aggiungere esplicitamente un nuovo repository remoto.(((git commands, remote))) +Per aggiungere un nuovo repository Git remoto con un nome breve a cui possa riferirti facilmente, esegui `git remote add `: [source,console] ---- @@ -87,8 +139,14 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- +//// Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +//// + +Ora potrai usare il nome `pb` alla riga di comando al posto dell'URL intero. +Se vuoi, per esempio, prendere tutte le informazioni che ha Paul, ma che non sono ancora nel tuo repository, puoi eseguire `git fetch pb`: + [source,console] ---- @@ -102,30 +160,48 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <>.) +Adesso la diramazione `master` di Paul è accessibile localmente come `pb/master` -- puoi farne il `merge` in uno delle tue diramazioni, o puoi scaricarla in una tua diramazione locale se vuoi controllarla. +(Cosa siano le diramazioni e come utilizzarle lo vedremo in maggior dettaglio in <>.) [[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +==== Scarica e Condividi coi Server Remoti -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +Come abbiamo appena visto, per scaricare dati da un progetto remoto, puoi fare:(((git commands, fetch))) [source,console] ---- $ git fetch ---- +//// The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +//// + +Il comando va sul progetto remoto e scarica tutti i dati dal progetto remoto che tu ancora non hai. +Dopo averlo fatto dovresti trovare i riferimenti a tutte le diramazioni di quel server, che potrai unire o controllare in qualsiasi momento. +//// If you clone a repository, the command automatically adds that remote repository under the name ``origin''. So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready. +//// +Quando cloni un repository, viene aggiunto automaticamente un repository remoto chiamato ``origin''. +In questo modo `git fetch origin` scarica le modifiche che sono state condividise con il server remoto da quando lo hai clonato (o dall'ultimo tuo aggiornamento). +È importante notare che il comando `git fetch` esegue soltanto lo scarico di queste informazioni nel tuo repository locale -- non le unisce automaticamente e non modifica alcun file su cui stai lavorando. +Quando sei pronto dovrai essere tu a unirle al tuo lavoro, manualmente. + +//// If your current branch is set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +//// + +Se la diramazione su cui sei è impostata per tracciarne una remota (vedi la prossima sezione e il <> per maggiori informazioni), puoi usare il comando `git pull` per scaricare e unire automaticamente questa diramazione remota nella tua diramazione attuale. +Questo potrebbe essere un modo più facile e più comodo per lavorare; e in modo predefinito, il comando `git clone` imposta automaticamente la tua diramazione `master` per tracciare la diramazione master remota (o comunque si chiami la diramazione predefinita) del server che hai clonato. +Eseguendo `git pull` vengono generalmente scaricati i dati dal server da cui hai fatto il clone originario e viene eseguito il tentativo di unirli automaticamente con il codice su cui stai lavorando. [[_pushing_remotes]] ==== Pushing to Your Remotes From aba908cf42438239bd114b6aa141a2416e2445b9 Mon Sep 17 00:00:00 2001 From: Fedro Date: Mon, 9 Sep 2019 18:38:56 +0200 Subject: [PATCH 38/44] completata la traduzione della sezione remotes --- book/02-git-basics/sections/remotes.asc | 124 +++++------------------- 1 file changed, 25 insertions(+), 99 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 0711491..e205e33 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,22 +1,4 @@ [[_remote_repos]] -//// -=== Working with Remotes - -To be able to collaborate on any Git project, you need to know how to manage your remote repositories. -Remote repositories are versions of your project that are hosted on the Internet or network somewhere. -You can have several of them, each of which generally is either read-only or read/write for you. -Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. -Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. -In this section, we'll cover some of these remote-management skills. - -[NOTE] -.Remote repositories can be on your local machine. -==== -It is entirely possible that you can be working with a ``remote'' repository that is, in fact, on the same host you are. -The word ``remote'' does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. -Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote. -==== -//// === Lavorare con i Repository Remoti Per poter collaborare con un qualsiasi progetto Git, devi sapere come amministrare i tuoi repository remoti. @@ -37,12 +19,6 @@ Lavorare con un repository remoto del genere comporta comunque tutte le operazio ==== Vedere i Propri Server Remoti -//// -To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) -It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see `origin` -- that is the default name Git gives to the server you cloned from: -//// - Per vedere i server remoti che hai configurato, puoi eseguire il comando `git remote`.(((git commands, remote))) Questo elenca i nomi brevi di ogni nodo remoto che hai configurato. Se hai clonato il tuo repository, dovresti vedere almeno `origin` -- che è il nome predefinito che Git da al server da cui cloni: @@ -61,10 +37,6 @@ $ git remote origin ---- -//// -You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: -//// - Puoi anche aggiungere `-v`, che mostra anche l'URL che Git ha associato a quel nome breve per utilizzarlo quando si legge o si scrive su questo repository remoto: [source,console] @@ -74,11 +46,6 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -//// -If you have more than one remote, the command lists them all. -For example, a repository with multiple remotes for working with several collaborators might look something like this. -//// - Se hai più di un server remoto, il comando li elenca tutti. Per esempio un repository, con multipli server remoti per lavorare con diversi collaboratori, appare così: @@ -98,31 +65,13 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -//// -This means we can pull contributions from any of these users pretty easily. -We may additionally have permission to push to one or more of these, though we can't tell that here. -//// - Questo significa che posso prendere facilmente i contributi da qualunque di questi utenti. Potremmo inoltre avere il permesso di inviare dati (push) ad uno o più di questi, anche se non ne possiamo parlare qui. -//// -Notice that these remotes use a variety of protocols; we'll cover more about this in <>. -//// - Nota che questi server remoti utilizzano una molteplicità di protocolli; al riguardo ne tratteremo di più in <>. -//// -==== Adding Remote Repositories -//// ==== Aggiungere un Repository Remoto -//// -We've mentioned and given some demonstrations of how the `git clone` command implicitly adds the `origin` remote for you. -Here's how to add a new remote explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: -//// - Abbiamo citato e dato alcune dimostrazioni di come il comando `git clone` aggiunga implicitamente il repository remoto `origin`. Ecco qui come aggiungere esplicitamente un nuovo repository remoto.(((git commands, remote))) Per aggiungere un nuovo repository Git remoto con un nome breve a cui possa riferirti facilmente, esegui `git remote add `: @@ -139,11 +88,6 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -//// -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: -//// - Ora potrai usare il nome `pb` alla riga di comando al posto dell'URL intero. Se vuoi, per esempio, prendere tutte le informazioni che ha Paul, ma che non sono ancora nel tuo repository, puoi eseguire `git fetch pb`: @@ -173,58 +117,40 @@ Come abbiamo appena visto, per scaricare dati da un progetto remoto, puoi fare:( $ git fetch ---- -//// -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. -//// - Il comando va sul progetto remoto e scarica tutti i dati dal progetto remoto che tu ancora non hai. Dopo averlo fatto dovresti trovare i riferimenti a tutte le diramazioni di quel server, che potrai unire o controllare in qualsiasi momento. -//// -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. -//// - Quando cloni un repository, viene aggiunto automaticamente un repository remoto chiamato ``origin''. In questo modo `git fetch origin` scarica le modifiche che sono state condividise con il server remoto da quando lo hai clonato (o dall'ultimo tuo aggiornamento). È importante notare che il comando `git fetch` esegue soltanto lo scarico di queste informazioni nel tuo repository locale -- non le unisce automaticamente e non modifica alcun file su cui stai lavorando. Quando sei pronto dovrai essere tu a unirle al tuo lavoro, manualmente. -//// -If your current branch is set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. -//// - Se la diramazione su cui sei è impostata per tracciarne una remota (vedi la prossima sezione e il <> per maggiori informazioni), puoi usare il comando `git pull` per scaricare e unire automaticamente questa diramazione remota nella tua diramazione attuale. Questo potrebbe essere un modo più facile e più comodo per lavorare; e in modo predefinito, il comando `git clone` imposta automaticamente la tua diramazione `master` per tracciare la diramazione master remota (o comunque si chiami la diramazione predefinita) del server che hai clonato. Eseguendo `git pull` vengono generalmente scaricati i dati dal server da cui hai fatto il clone originario e viene eseguito il tentativo di unirli automaticamente con il codice su cui stai lavorando. [[_pushing_remotes]] -==== Pushing to Your Remotes +==== Condividi coi Server Remoti -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push `.(((git commands, push))) -If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +Quando il tuo progetto raggiunge uno stato che vuoi condividere, devi caricarlo sul server principale. +Il comando per farlo è semplice: `git push `.(((git commands, push))) +Se vuoi condividere la tua diramazione `master` sul tuo server `origin` (lo ripeto: clonando vengono generalmente definiti automaticamente questi nomi), puoi eseguire il comando seguente per caricare ogni commit di cui hai fatto il back up sul server: [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push. -See <> for more detailed information on how to push to remote servers. +Questo comando funziona solamente se hai clonato il tuo progetto da un server su cui hai i permessi di scrittura e se nessun altro ha caricato modifiche nel frattempo. +Se cloni un repository assieme ad altri e questi caricano delle modifiche sul server, il tuo invio verrà rifiutato. +Dovrai prima scaricare le loro modifiche e incorporarle con le tue per poterle poi inviare. +Vedi il <> per maggiori informazioni su come fare il `push` su server remoti. [[_inspecting_remote]] -==== Inspecting a Remote +==== Controllare un Server Remoto -If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +Se vuoi più informazioni su una particolare server remoto, puoi usare il comando `git remote show `.(((git commands, remote))) +Se esegui il comando con un nome particolare, per esempio `origin`, avrai qualcosa di simile: [source,console] ---- @@ -242,12 +168,12 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. +che mostra gli URL del repository remoto oltre alle informazioni sulle diramazioni tracciate. +Il comando ti dice anche che, se esegui `git pull` mentre sei su `master`, integrerà automaticamente le modifiche sul `master` remoto dopo aver scaricato tutti i riferimenti remoti. +iInoltre elenca anche i riferimenti remoti che hai già scaricato. -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +Questo è un esempio semplice di quanto probabilmente vedrai. +Tuttavia, quando usi intensamente Git potresti trovare molte più informazioni con `git remote show`: [source,console] ---- @@ -273,13 +199,13 @@ $ git remote show origin master pushes to master (up to date) ---- -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`. +Questo comando mostra quale diramazione viene scaricata automaticamente quando esegui `git push` mentre sei su certe diramazioni. +Mostra anche quali diramazioni remote non hai ancora scaricato, quali diramazioni remote hai in locale che sono state rimosse dal server e le diramazioni locali che sono in grado di unirsi automaticamente con le proprie corrispettive, tracciate in remoto, quando esegui `git pull`. -==== Renaming and Removing Remotes +==== Rimuovere e Rinominare Server Remoti -You can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +Puoi eseguire `git remote rename` per cambiare il nome breve di un server remoto.(((git commands, remote))) +Se vuoi per esempio rinominare `pb` in `paul`, puoi farlo con `git remote rename`: [source,console] ---- @@ -289,10 +215,10 @@ origin paul ---- -It's worth mentioning that this changes all your remote-tracking branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. +Vale la pena ricordare che questo cambia anche tutti i nomi delle diramazioni tracciate in remoto. +Quello che prima veniva chiamato `pb/master` ora è `paul/master`. -If you want to remove a remote for some reason -- you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore -- you can either use `git remote remove` or `git remote rm`: +Se, per qualsiasi ragione, vuoi rimuovere un server remoto (hai spostato il server o non stai più usando un particolare mirror, o magari un collaboratore non contribuisce più) puoi usare `git remote remove` oppure `git remote rm`: [source,console] ---- @@ -301,4 +227,4 @@ $ git remote origin ---- -Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted. +Quando hai cancellato in questo modo il riferimento a un server remoto, vengono cancellate anche tutte le diramazioni tracciate in remoto e le impostazioni di configurazione associate con questo server remoto. From 88b47e1c5c09efe53c418994e2604cdaf8a4171d Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 10 Sep 2019 00:50:35 +0200 Subject: [PATCH 39/44] inizio traduzione sez. tagging --- book/02-git-basics/sections/tagging.asc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index a046cab..5d10926 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,11 +1,15 @@ [[r_git_tagging]] -=== Tagging +=== Etichettare (((tags))) Like most VCSs, Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on). In this section, you'll learn how to list the available tags, how to create new tags, and what the different types of tags are. +Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) come importanti dei punti specifici della cronologia di un repository. +Le persone generalmente usano questa funzionalità per segnare i punti di rilascio (v1.0, v2.0 e così via). +In questa sezione, imparerai come elencare le etichette esistenti, come creare e cancellare le etichette e i diversi tipi di etichette disponibili. + ==== Listing Your Tags Listing the available tags in Git is straightforward. From 4f9096a8b46e2fd0c2c8b48bd38458acdb956637 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 10 Sep 2019 15:00:14 +0200 Subject: [PATCH 40/44] iniziato traduzione sezione tagging --- book/02-git-basics/sections/tagging.asc | 117 ++++++++++++++++++------ 1 file changed, 91 insertions(+), 26 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 5d10926..3edb110 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,36 +1,32 @@ -[[r_git_tagging]] +[[_git_tagging]] === Etichettare (((tags))) -Like most VCSs, Git has the ability to tag specific points in history as being important. -Typically people use this functionality to mark release points (v1.0, and so on). -In this section, you'll learn how to list the available tags, how to create new tags, and what the different types of tags are. - Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) come importanti dei punti specifici della cronologia di un repository. Le persone generalmente usano questa funzionalità per segnare i punti di rilascio (v1.0, v2.0 e così via). In questa sezione, imparerai come elencare le etichette esistenti, come creare e cancellare le etichette e i diversi tipi di etichette disponibili. -==== Listing Your Tags +==== Elencare le Etichette -Listing the available tags in Git is straightforward. -Just type `git tag`:(((git commands, tag))) +Listing the existing tags in Git is straightforward. +Just type `git tag` (with optional `-l` or `--list`):(((git commands, tag))) [source,console] ---- $ git tag -v0.1 -v1.3 +v1.0 +v2.0 ---- -This command lists the tags in alphabetical order; the order in which they appear has no real importance. +This command lists the tags in alphabetical order; the order in which they are displayed has no real importance. -You can also search for tags with a particular pattern. +You can also search for tags that match a particular pattern. The Git source repo, for instance, contains more than 500 tags. -If you're only interested in looking at the 1.8.5 series, you can run this: +If you're interested only in looking at the 1.8.5 series, you can run this: [source,console] ---- -$ git tag -l 'v1.8.5*' +$ git tag -l "v1.8.5*" v1.8.5 v1.8.5-rc0 v1.8.5-rc1 @@ -43,17 +39,25 @@ v1.8.5.4 v1.8.5.5 ---- +[NOTE] +.Listing tag wildcards requires `-l` or `--list` option +==== +If you want just the entire list of tags, running the command `git tag` implicitly assumes you want a listing and provides one; the use of `-l` or `--list` in this case is optional. + +If, however, you're supplying a wildcard pattern to match tag names, the use of `-l` or `--list` is mandatory. +==== + ==== Creating Tags -Git uses two main types of tags: lightweight and annotated. +Git supports two types of tags: _lightweight_ and _annotated_. -A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit. +A lightweight tag is very much like a branch that doesn't change -- it's just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. -They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). +They're checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. -[[r_annotated_tags]] +[[_annotated_tags]] ==== Annotated Tags (((tags, annotated))) @@ -62,7 +66,7 @@ The easiest way is to specify `-a` when you run the `tag` command:(((git command [source,console] ---- -$ git tag -a v1.4 -m 'my version 1.4' +$ git tag -a v1.4 -m "my version 1.4" $ git tag v0.1 v1.3 @@ -96,8 +100,8 @@ That shows the tagger information, the date the commit was tagged, and the annot (((tags, lightweight))) Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file – no other information is kept. -To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option: +This is basically the commit checksum stored in a file -- no other information is kept. +To create a lightweight tag, don't supply any of the `-a`, `-s`, or `-m` options, just provide a tag name: [source,console] ---- @@ -178,12 +182,12 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ... ---- -[[r_sharing_tags]] +[[_sharing_tags]] ==== Sharing Tags By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches – you can run `git push origin [tagname]`. +This process is just like sharing remote branches -- you can run `git push origin `. [source,console] ---- @@ -213,10 +217,71 @@ To git@github.com:schacon/simplegit.git Now, when someone else clones or pulls from your repository, they will get all your tags as well. +[NOTE] +.`git push` pushes both types of tags +==== +Pushing tags using `git push --tags` does not distinguish between lightweight and annotated tags; there is no simple option that allows you to select just one type for pushing. +==== + +==== Deleting Tags + +To delete a tag on your local repository, you can use `git tag -d `. +For example, we could remove our lightweight tag above as follows: + +[source,console] +---- +$ git tag -d v1.4-lw +Deleted tag 'v1.4-lw' (was e7d5add) +---- + +Note that this does not remove the tag from any remote servers. +There are two common variations for deleting a tag from a remote server. + +The first variation is `git push :refs/tags/`: + +[source,console] +---- +$ git push origin :refs/tags/v1.4-lw +To /git@github.com:schacon/simplegit.git + - [deleted] v1.4-lw +---- + +The way to interpret the above is to read it as the null value before the colon is being pushed to the remote tag name, effectively deleting it. + +The second (and more intuitive) way to delete a remote tag is with: + +[source,console] +---- +$ git push origin --delete +---- + ==== Checking out Tags -You can't really check out a tag in Git, since they can't be moved around. -If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag: +If you want to view the versions of files a tag is pointing to, you can do a `git checkout` of that tag, although this puts your repository in ``detached HEAD'' state, which has some ill side effects: + +[source,console] +---- +$ git checkout 2.0.0 +Note: checking out '2.0.0'. + +You are in 'detached HEAD' state. You can look around, make experimental +changes and commit them, and you can discard any commits you make in this +state without impacting any branches by performing another checkout. + +If you want to create a new branch to retain commits you create, you may +do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b + +HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final + +$ git checkout 2.0-beta-0.1 +Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final +HEAD is now at df3f601... add atlas.json and cover image +---- + +In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except by the exact commit hash. +Thus, if you need to make changes -- say you're fixing a bug on an older version, for instance -- you will generally want to create a branch: [source,console] ---- @@ -224,4 +289,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Of course if you do this and do a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +If you do this and make a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. From ec5357007384f8ae65db597b94e5baa98158ec68 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 10 Sep 2019 19:53:01 +0200 Subject: [PATCH 41/44] completata la traduzione della sezione tagging --- book/02-git-basics/sections/tagging.asc | 115 ++++++++++++------------ 1 file changed, 57 insertions(+), 58 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 3edb110..39d1602 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -8,8 +8,8 @@ In questa sezione, imparerai come elencare le etichette esistenti, come creare e ==== Elencare le Etichette -Listing the existing tags in Git is straightforward. -Just type `git tag` (with optional `-l` or `--list`):(((git commands, tag))) +Elencare le etichette esistenti in Git è facilissimo. +Digita semplicemente `git tag` (eventualmente con `-l` or `--list`):(((git commands, tag))) [source,console] ---- @@ -18,11 +18,11 @@ v1.0 v2.0 ---- -This command lists the tags in alphabetical order; the order in which they are displayed has no real importance. +Questo comando elenca le etichette in ordine alfabetico; l'ordine con cui sono visualizzate non ha importanza. -You can also search for tags that match a particular pattern. -The Git source repo, for instance, contains more than 500 tags. -If you're interested only in looking at the 1.8.5 series, you can run this: +Puoi inoltre cercare etichette che corrispondono ad uno schema specifico. +Il repository sorgente di Git, per esempio, contiene più di 500 etichette. +Se sei interessato a vedere solo quelli della serie 1.8.5, puoi eseguire: [source,console] ---- @@ -40,29 +40,28 @@ v1.8.5.5 ---- [NOTE] -.Listing tag wildcards requires `-l` or `--list` option +.Elencare i tag jolly richiede l'opzione `-l` o `--list` ==== -If you want just the entire list of tags, running the command `git tag` implicitly assumes you want a listing and provides one; the use of `-l` or `--list` in this case is optional. +Se si desidera solo l'elenco completo dei tag, l'esecuzione del comando `git tag` presuppone implicitamente che si desidera una semplice elencazione e ne fornisce una. -If, however, you're supplying a wildcard pattern to match tag names, the use of `-l` or `--list` is mandatory. +Tuttavia, se stai fornendo uno schema di caratteri jolly per far corrispondere i nomi dei tag, l'uso di `-l` o `--list` è obbligatorio. ==== -==== Creating Tags +==== Creare Etichette Git supports two types of tags: _lightweight_ and _annotated_. - -A lightweight tag is very much like a branch that doesn't change -- it's just a pointer to a specific commit. - -Annotated tags, however, are stored as full objects in the Git database. -They're checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). -It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. +Git rende disponibili due tipi di etichette: semplici (_lightweight_, ndt) e annotate (_annotated_, ndt). +Un'etichetta semplice è molto simile a una ramificazione che non cambia mai -- è semplicemente un riferimento ad una commit specifica. +Le etichette annotate, al contrario, sono salvate come oggetti complessi nel database Git. +Ne viene calcolato il checksum, contengono il nome, l'email e la data di chi ha inserito l'etichetta, hanno un messaggio d'etichetta; e possono essere firmate e verificate con GPG (GNU Privacy Guard). +Generalmente si raccomanda di usare le etichette annotate così da avere tutte queste informazioni, ma se vuoi aggiungere un'etichetta temporanea o per qualche ragione non vuoi salvare quelle informazioni aggiuntive, hai sempre a disposizione le etichette semplici. [[_annotated_tags]] -==== Annotated Tags +==== Etichette Annotate (((tags, annotated))) -Creating an annotated tag in Git is simple. -The easiest way is to specify `-a` when you run the `tag` command:(((git commands, tag))) +Creare un'etichetta annotate in Git è semplice. +Il modo più facile è specificare `-a` quando esegui il comando `tag`:(((git commands, tag))) [source,console] ---- @@ -73,10 +72,10 @@ v1.3 v1.4 ---- -The `-m` specifies a tagging message, which is stored with the tag. -If you don't specify a message for an annotated tag, Git launches your editor so you can type it in. +`-m` specifica il messaggio per l'etichetta, che viene salvato con la stessa. +Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla. -You can see the tag data along with the commit that was tagged by using the `git show` command: +Puoi vedere i dati dell'etichetta assieme alla commit etichettata con il comando `git show`: [source,console] ---- @@ -94,14 +93,14 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. +Questo mostra le informazioni di chi ha creato l'etichetta, la data in cui la commit è stata etichettata e il messaggio, prima di mostrare le informazioni della commit. -==== Lightweight Tags +==== Etichette semplici (((tags, lightweight))) -Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file -- no other information is kept. -To create a lightweight tag, don't supply any of the `-a`, `-s`, or `-m` options, just provide a tag name: +Un altro modo per etichettare una commit è con le etichette semplici. +Questo in pratica è salvare il checksum della commit in un file -- non viene salvata nessun'altra informazione. +Per creare un'etichetta semplice, non usare nessuna delle opzioni `-a`, `s` o `-m` ma fornire solamente un nome di etichetta: [source,console] ---- @@ -114,8 +113,8 @@ v1.4-lw v1.5 ---- -This time, if you run `git show` on the tag, you don't see the extra tag information.(((git commands, show))) -The command just shows the commit: +Questa volta, se esegui `git show` per l'etichetta, non vedrai altre informazioni aggiuntive.(((git commands, show))) +Il comando mostra solamente la commit: [source,console] ---- @@ -127,10 +126,10 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -==== Tagging Later +==== Etichettare Successivamente -You can also tag commits after you've moved past them. -Suppose your commit history looks like this: +Puoi etichettare anche commit passate. +Supponiamo che la cronologia delle tue commit sia questa: [source,console] ---- @@ -147,16 +146,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- -Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit. -You can add it after the fact. -To tag that commit, you specify the commit checksum (or part of it) at the end of the command: +Supponiamo che tu abbia dimenticato di etichettare il progetto alla v1.2, che era con la commit ``updated rakefile''. +Puoi sempre aggiungerla in un secondo momento. +Per etichettare questa commit, alla fine del comando, devi indicare il checksum (o parte di esso) della commit: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -You can see that you've tagged the commit:(((git commands, tag))) +Puoi vedere che hai etichettato la commit:(((git commands, tag))) [source,console] ---- @@ -183,11 +182,11 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== Sharing Tags +==== Condividere le Etichette -By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) -You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches -- you can run `git push origin `. +Per impostazione predefinita il comando `git push` non invia le etichette sui server remoti. +Devi farlo esplicitamente, dopo averle create, per condividerle con il server. +Questo procedimento è come la condivisione delle diramazioni remote -- puoi eseguire `git push origin `. [source,console] ---- @@ -201,8 +200,8 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. -This will transfer all of your tags to the remote server that are not already there. +Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzione `--tags` col comando `git push`. +Questo trasferirà al server remoto tutte le tue etichette che non sono ancora presenti. [source,console] ---- @@ -215,18 +214,18 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Now, when someone else clones or pulls from your repository, they will get all your tags as well. +Quando qualcuno clonerà il repository o scaricherà gli aggiornamenti, scaricherà anche tutte le tue etichette. [NOTE] -.`git push` pushes both types of tags +.`git push` invia entrambi i tipi di etichette ==== -Pushing tags using `git push --tags` does not distinguish between lightweight and annotated tags; there is no simple option that allows you to select just one type for pushing. +Inviare le etichette utilizzando `git push --tags` non fa distinzione tra etichette leggere ed annotate; non c'é un'opzione semplice che consenta di selezionare soltanto un tipo per l'invio. ==== -==== Deleting Tags +==== Cancellare le Etichette -To delete a tag on your local repository, you can use `git tag -d `. -For example, we could remove our lightweight tag above as follows: +Per cancellare un'etichetta dal tuo repository locale puoi utilizzare `git tag -d `. +Ad esempio potremmo rimuovere la nostra etichetta semplice creata precedentemente in questo modo: [source,console] ---- @@ -234,10 +233,10 @@ $ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add) ---- -Note that this does not remove the tag from any remote servers. -There are two common variations for deleting a tag from a remote server. +Da notare che questo comando non rimuove l'etichetta da nessun server remoto. +Ci sono due varianti comuni per cancellare un'etichetta da un server remoto. -The first variation is `git push :refs/tags/`: +La prima variante é `git push :refs/tags/`: [source,console] ---- @@ -246,18 +245,18 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -The way to interpret the above is to read it as the null value before the colon is being pushed to the remote tag name, effectively deleting it. +Il modo di interpretare quanto sopra scritto è quello di leggerlo come se il valore null prima dei due punti venga inviato come nome dell'etichetta remota, di fatto cancellandolo. -The second (and more intuitive) way to delete a remote tag is with: +Il secondo (e più intuitivo) modo per cancellare un'etichetta remota é con: [source,console] ---- $ git push origin --delete ---- -==== Checking out Tags +==== Fare il Check Out delle Etichette -If you want to view the versions of files a tag is pointing to, you can do a `git checkout` of that tag, although this puts your repository in ``detached HEAD'' state, which has some ill side effects: +Se vuoi vedere le versioni dei file contrassegnati da un'etichetta, puoi fare un `git checkout` di questa etichetta, anche se questo mette il tuo repository in uno stato di ``detached HEAD'', che ha alcuni effetti collaterali pericolosi: [source,console] ---- @@ -280,8 +279,8 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append HEAD is now at df3f601... add atlas.json and cover image ---- -In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except by the exact commit hash. -Thus, if you need to make changes -- say you're fixing a bug on an older version, for instance -- you will generally want to create a branch: +Nello stato ``detached HEAD'', se esegui modifiche e poi crei una commit, l'etichetta rimarrà la stessa ma la tua nuova commit non apparterrà a nessuna diramazione e sarà irraggiungibile, tranne che tramite il suo esatto hash. +Quindi, se hai necessità di fare modifiche -- diciamo che tu abbia corretto un bug su una versione più vecchia, ad esempio -- normalmente dovrai creare una diramazione: [source,console] ---- @@ -289,4 +288,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -If you do this and make a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +Se fai così e crei una commit, la tua diramazione `version2` sarà leggermente diversa dalla tua etichetta `v2.0.0` poichè andrà avanti con le tue nuove modifiche, quindi agisci con cautela. From 84a6e431d5b531fd1b06ef19a880f5d989a500b3 Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 10 Sep 2019 19:57:10 +0200 Subject: [PATCH 42/44] inserimento originale inglese della sezione aliases --- book/02-git-basics/sections/aliases.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 3ce0fd8..2c9c7c0 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,4 +1,4 @@ -[[r_git_aliases]] +[[_git_aliases]] === Git Aliases (((aliases))) @@ -33,7 +33,7 @@ This makes the following two commands equivalent: [source,console] ---- $ git unstage fileA -$ git reset HEAD fileA +$ git reset HEAD -- fileA ---- This seems a bit clearer. @@ -66,5 +66,5 @@ We can demonstrate by aliasing `git visual` to run `gitk`: [source,console] ---- -$ git config --global alias.visual "!gitk" +$ git config --global alias.visual '!gitk' ---- From 95f77c95df9adccd5c5cc616b5a4a8a38da6a33e Mon Sep 17 00:00:00 2001 From: Fedro Date: Tue, 10 Sep 2019 23:05:46 +0200 Subject: [PATCH 43/44] completata la traduzione della sezione aliases e del capitolo 2 --- book/02-git-basics/sections/aliases.asc | 38 ++++++++++++------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 2c9c7c0..1025bea 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,13 +1,13 @@ [[_git_aliases]] -=== Git Aliases +=== Alias di Git (((aliases))) -Before we finish this chapter on basic Git, there's just one little tip that can make your Git experience simpler, easier, and more familiar: aliases. -We won't refer to them or assume you've used them later in the book, but you should probably know how to use them. +Prima di terminare questo capitolo sulle basi di Git, ecco giusto un piccolo suggerimento per rendere la tua esperienza con Git più semplice, più facile e più familiare: gli alias. +In seguito nel libro non ci riferiremo ad essi né presumeremo che tu li abbia usati, ma probabilmente dovresti sapere come realizzarli. -Git doesn't automatically infer your command if you type it in partially. -If you don't want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`.(((git commands, config))) -Here are a couple of examples you may want to set up: +Git non indovina automaticamente il tuo comando se ne digiti solo una parte. +Se non vuoi vuole scrivere tutto il testo di un qualsiasi comando Git puoi configurare facilmente un alias per ogni comando usando `git config`.(((git commands, config))) +Di seguito ci sono alcuni esempi che potresti voler usare: [source,console] ---- @@ -17,18 +17,18 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -This means that, for example, instead of typing `git commit`, you just need to type `git ci`. -As you go on using Git, you'll probably use other commands frequently as well; don't hesitate to create new aliases. +Questo significa che, per esempio, invece di digitare `git commit`, dovrai scrivere solo `git ci`. +Andando avanti con l'uso di Git userai alcuni comandi con maggiore frequenza: non esitare a creare nuovi alias. -This technique can also be very useful in creating commands that you think should exist. -For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: +Questa tecnica può essere anche molto utile per creare comandi che ritieni dovrebbero esistere. +Per esempio, per correggere un problema comune in cui si incorre quando si vuole rimuovere un file dall'area di stage, puoi aggiungere il tuo alias `unstage` in Git: [source,console] ---- $ git config --global alias.unstage 'reset HEAD --' ---- -This makes the following two commands equivalent: +Questo rende equivalenti i due comandi seguenti: [source,console] ---- @@ -36,15 +36,15 @@ $ git unstage fileA $ git reset HEAD -- fileA ---- -This seems a bit clearer. -It's also common to add a `last` command, like this: +Questo sembra un po' più chiaro. +É anche abituale aggiungere un comando `last` come questo: [source,console] ---- $ git config --global alias.last 'log -1 HEAD' ---- -This way, you can see the last commit easily: +In questo modo puoi vedere facilmente l'ultima commit: [source,console] ---- @@ -58,11 +58,11 @@ Date: Tue Aug 26 19:48:51 2008 +0800 Signed-off-by: Scott Chacon ---- -As you can tell, Git simply replaces the new command with whatever you alias it for. -However, maybe you want to run an external command, rather than a Git subcommand. -In that case, you start the command with a `!` character. -This is useful if you write your own tools that work with a Git repository. -We can demonstrate by aliasing `git visual` to run `gitk`: +Come puoi immaginare, Git semplicemente sostituisce il nuovo comando con qualsiasi cosa corrisponda all'alias. +Potresti anche voler eseguire un comando esterno, piuttosto che uno di Git. +In questo caso devi iniziare il comando con un carattere "!". +Questo è utile se stai scrivendo degli strumenti di lavoro personali per gestire un repository Git. +Possiamo illustrarlo creando l'alias `git visual` per eseguire `gitk`: [source,console] ---- From 4f7f4d4df2b384337f72614cb02b71c5d5fe9e09 Mon Sep 17 00:00:00 2001 From: Fedro Date: Wed, 18 Sep 2019 19:31:50 +0200 Subject: [PATCH 44/44] piccoli errata corrige --- book/02-git-basics/sections/aliases.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 1025bea..a17bf06 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -6,7 +6,7 @@ Prima di terminare questo capitolo sulle basi di Git, ecco giusto un piccolo sug In seguito nel libro non ci riferiremo ad essi né presumeremo che tu li abbia usati, ma probabilmente dovresti sapere come realizzarli. Git non indovina automaticamente il tuo comando se ne digiti solo una parte. -Se non vuoi vuole scrivere tutto il testo di un qualsiasi comando Git puoi configurare facilmente un alias per ogni comando usando `git config`.(((git commands, config))) +Se non vuoi scrivere tutto il testo di un qualsiasi comando Git puoi configurare facilmente un alias per ogni comando usando `git config`.(((git commands, config))) Di seguito ci sono alcuni esempi che potresti voler usare: [source,console]