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/command-line.asc b/book/01-introduction/sections/command-line.asc index 0159b8a..a1e28a8 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,9 +1,25 @@ -=== La riga di comando +//// +=== 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/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 7eb9c91..982b28d 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,28 +1,93 @@ -[[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. +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.) +//// + +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. +(Prevedibilmente é necessario trovarsi da qualche parte in un repository di Git affinchè questa opzione funzioni correttamente). + +//// 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. +//// + +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 +//// -The first thing you should do when you install Git is to set your user name and e-mail address. +==== 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] ---- @@ -30,31 +95,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 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. +//// +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, 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: +//// + +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] ==== -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. +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 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: +//// + +Per controllare le tue impostazioni puoi usare il comando `git config --list` che elenca tutte le impostazioni attuali di Git: [source,console] ---- @@ -68,13 +203,37 @@ 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] ---- $ 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 +---- + diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 914f37a..025423b 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -1,87 +1,271 @@ +//// === 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`: - $ yum install git +[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[]. +//// + + +(((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`: -If you're on a Debian-based distribution like Ubuntu, try apt-get: +[source,console] +---- +$ sudo dnf install git-all +---- - $ apt-get install git +Se usi una distribuzione basata su Debian, come Ubuntu, prova `apt`: -For more options, there are instructions for installing on several different Unix flavors on the Git website, at http://git-scm.com/download/linux[]. +[source,console] +---- +$ sudo apt install git-all +---- -==== Installing on Mac +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[]. -(((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[]. +//// + +==== 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))) 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[]. -Another easy way to get Git installed is by installing GitHub for Windows. +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 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]. +//// + +==== 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 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: +//// + +==== 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] +---- +$ 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): +//// + +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] +---- +$ 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: +//// - $ yum install curl-devel expat-devel gettext-devel \ - openssl-devel zlib-devel +Se stai utilizzando una distribuzione basata su Debian (Debian/Ubuntu/derivate di Ubuntu) ti serve anche il pacchetto `install-info`: - $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ - libz-dev libssl-dev +[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] +---- +$ 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 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: +//// + +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. - $ 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 +Poi, compilalo ed installalo: +[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: +//// + +Dopo aver fatto questo, puoi scaricare gli aggiornamenti di Git con Git stesso : - $ git clone git://git.kernel.org/pub/scm/git/git.git +[source,console] +---- +$ git clone git://git.kernel.org/pub/scm/git/git.git +---- 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. diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 3ce0fd8..a17bf06 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,13 +1,13 @@ -[[r_git_aliases]] -=== 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 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,34 +17,34 @@ $ 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] ---- $ git unstage fileA -$ git reset HEAD 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,13 +58,13 @@ 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] ---- -$ git config --global alias.visual "!gitk" +$ git config --global alias.visual '!gitk' ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 6b5d2b1..3d64dbe 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,25 +1,88 @@ -[[r_getting_a_repo]] +[[_getting_a_repo]] +//// === Getting a Git Repository +//// +=== Ottenere un 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. -The second clones an existing Git repository from another server. +//// +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 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: +[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: +//// -If you're starting to track an existing project in Git, you need to go to the project's directory and type +e digitare: [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))) 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] ---- @@ -28,29 +91,51 @@ $ 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. -[[r_git_cloning]] +[[_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 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 `.(((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 [url]`.(((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 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, 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] ---- @@ -58,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. +<> 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. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 3167796..37d5159 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,46 +1,52 @@ -=== Recording Changes to the Repository +=== Salvare le modifiche sul 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. +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. -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. +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. -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. +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. -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] +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. -[[r_checking_status]] -==== Checking 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]] +==== Controlla lo stato dei tuoi file + +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: -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: [source,console] ---- $ 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. -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] ---- $ 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 +55,31 @@ 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. -[[r_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: +[[_tracking_files]] +==== Tracciare Nuovi File + +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] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -78,20 +87,21 @@ 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))) -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: [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 +115,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: +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] ---- $ 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) @@ -122,16 +135,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 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: [source,console] ---- $ 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) @@ -146,18 +160,19 @@ 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] ---- $ 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) @@ -165,9 +180,11 @@ 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] ---- @@ -179,15 +196,19 @@ 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. +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. + -[[r_ignoring]] -==== Ignoring Files +[[_ignoring]] +==== 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] ---- @@ -196,69 +217,81 @@ $ 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. -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. +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: +Queste sono le regole per i pattern che puoi usare in `.gitignore`: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* 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] ---- -# no .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 root TODO file, not subdir/TODO +# ignora solo il TODO nella root, e non subdir/TOD /TODO -# ignore all files in the build/ directory +# 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 .txt files in the doc/ directory -doc/**/*.txt +# 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. +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 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`.) + +È oltre gli scopi di questo libro entrare nei dettagli dei file `.gitignore` multipli; per i dettagli vedi `man gitignore`. ==== -[[r_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))) -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. +[[_git_diff_staged]] +==== Mostra le modifiche dentro e fuori lo `stage` + +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'è. -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: +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] ---- $ 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) @@ -267,7 +300,7 @@ 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] ---- @@ -281,18 +314,18 @@ 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 ---- -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. +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`. -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: +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] ---- @@ -306,17 +339,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. +È 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] ---- $ 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 +364,7 @@ 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] ---- @@ -340,12 +375,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): +e `git diff --cached` per vedere cos'è già in `stage` (`--staged` e `--cached` sono sinonimi) [source,console] ---- @@ -359,41 +394,40 @@ 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 +.Git Diff in uno Strumento Esterno ==== -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. +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. ==== -[[r_committing_changes]] -==== Committing Your Changes +[[_committing_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. +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))) +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))) -The editor displays the following text (this example is a Vim screen): +L'editor visualizzerà il testo (questo è un esempio della schermata di Vim): [source] ---- @@ -401,6 +435,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 @@ -411,13 +447,13 @@ 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`. -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). +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`. +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). -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +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] ---- @@ -427,24 +463,26 @@ $ 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. +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. -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. -==== 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] ---- $ 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 +495,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. +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. -[[r_removing_files]] -==== 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. +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. -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: +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] ---- @@ -483,7 +523,8 @@ 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] ---- @@ -491,77 +532,79 @@ $ 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) deleted: PROJECTS.md ---- -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. -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. +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. -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: +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 that end with `~`. +Questo comando rimuove tutti i file il cui nome termina con una `~`. -[[r_git_mv]] -==== Moving Files +[[_git_mv]] +==== 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. +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. -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 +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] ---- $ 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) renamed: README.md -> README ---- -However, this is equivalent to running something like this: +Comunque, questo è equivalente ad eseguire qualcosa come: [source,console] ---- @@ -570,6 +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 `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. +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. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 442145b..e205e33 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,18 +1,27 @@ -[[r_remote_repos]] -=== Working with Remotes +[[_remote_repos]] +=== Lavorare con i Repository Remoti -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. +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. -==== Showing Your Remotes +[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. +==== -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: + +==== Vedere i Propri Server Remoti + +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] ---- @@ -28,7 +37,7 @@ $ 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] ---- @@ -37,8 +46,8 @@ 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] ---- @@ -56,14 +65,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. +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 -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]`: +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] ---- @@ -77,8 +88,9 @@ 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] ---- @@ -92,53 +104,53 @@ 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 <>.) -[[r_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +[[_fetching_and_pulling]] +==== 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 [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. -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 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. -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 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))) -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. -[[r_pushing_remotes]] -==== Pushing to Your Remotes +[[_pushing_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 [remote-name] [branch-name]`.(((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 pull down 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. -[[r_inspecting_remote]] -==== Inspecting a Remote +[[_inspecting_remote]] +==== Controllare un Server Remoto -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 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] ---- @@ -156,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] ---- @@ -187,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 branches that are automatically merged 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`. -==== Removing and Renaming Remotes +==== Rimuovere e Rinominare Server Remoti -If you want to rename a reference 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] ---- @@ -203,14 +215,16 @@ origin paul ---- -It's worth mentioning that this changes your remote 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 use `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] ---- -$ git remote rm paul +$ git remote remove paul $ git remote origin ---- + +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. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index a046cab..39d1602 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,32 +1,32 @@ -[[r_git_tagging]] -=== 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))) +Elencare le etichette esistenti in Git è facilissimo. +Digita semplicemente `git tag` (eventualmente con `-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. +Questo comando elenca le etichette in ordine alfabetico; l'ordine con cui sono visualizzate non ha importanza. -You can also search for tags with 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: +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] ---- -$ git tag -l 'v1.8.5*' +$ git tag -l "v1.8.5*" v1.8.5 v1.8.5-rc0 v1.8.5-rc1 @@ -39,36 +39,43 @@ v1.8.5.4 v1.8.5.5 ---- -==== Creating Tags +[NOTE] +.Elencare i tag jolly richiede l'opzione `-l` o `--list` +==== +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. -Git uses two main types of tags: lightweight and annotated. +Tuttavia, se stai fornendo uno schema di caratteri jolly per far corrispondere i nomi dei tag, l'uso di `-l` o `--list` è obbligatorio. +==== -A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit. +==== Creare Etichette -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). -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 supports two types of tags: _lightweight_ and _annotated_. +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. -[[r_annotated_tags]] -==== 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] ---- -$ 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 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] ---- @@ -86,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 the `-a`, `-s`, or `-m` option: +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] ---- @@ -106,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] ---- @@ -119,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] ---- @@ -139,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] ---- @@ -174,12 +181,12 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ... ---- -[[r_sharing_tags]] -==== 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 [tagname]`. +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] ---- @@ -193,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] ---- @@ -207,12 +214,73 @@ 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` invia entrambi i tipi di etichette +==== +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. +==== + +==== Cancellare le Etichette + +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] +---- +$ git tag -d v1.4-lw +Deleted tag 'v1.4-lw' (was e7d5add) +---- + +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. + +La prima variante é `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 +---- + +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. -==== Checking out Tags +Il secondo (e più intuitivo) modo per cancellare un'etichetta remota é con: + +[source,console] +---- +$ git push origin --delete +---- + +==== Fare il Check Out delle Etichette + +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] +---- +$ 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 +---- -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: +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] ---- @@ -220,4 +288,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. +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. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 01f018d..d2edf5a 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_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. +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. -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: +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. +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. -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. +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. -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: +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,20 +29,29 @@ $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit – the second commit replaces the results of the first. +Ti ritroverai con una sola commit: la seconda sovrascrive la prima. + +[NOTE] +==== +É 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. + +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''. +==== -[[r_unstaging]] -==== Unstaging a Staged File -The next two sections demonstrate how to wrangle 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: +[[_unstaging]] +==== Rimuovere un file dall'area di `stage` + +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] ---- -$ git add . +$ git add * $ git status On branch master Changes to be committed: @@ -52,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] ---- @@ -74,22 +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] ===== -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. +É 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] ---- @@ -100,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] ---- @@ -115,16 +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 -- [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. +É 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ù. diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 21b6aac..5ad7a3f 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ -[[r_viewing_history]] -=== Viewing the Commit History +[[_viewing_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. +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`. -These examples use a very simple project called ``simplegit''. -To get the project, run +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 +36,14 @@ 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. +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. -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. +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. -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: +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 +87,13 @@ 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 +128,14 @@ 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 +145,8 @@ 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))) [source,console] ---- @@ -156,37 +156,35 @@ 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. -[[rpretty_format]] -.Useful options for `git log --pretty=format` +[[pretty_format]] +.Opzioni utili per `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 e-mail -| `%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 +| Opzione | Descrizione dell'Output +| `%H` | Hash della commit +| `%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. -We'll cover this distinction a bit more in <>. +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*. -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: +Le opzioni `oneline` e `format` sono particolarmente utili con un'altra opzione di `log` chiamata `--graph`. Questa aggiunge un piccolo grafico ASCII carino che mostra le diramazioni e le unioni della cronologia, che possiamo vedere nella copia del repository del progetto Grit: [source,console] ---- @@ -203,80 +201,86 @@ $ 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. +Questo tipo di output diventerà più interessante quando ci inoltreremo nel _brancing_ e nel _merging_ nel prossimo capitolo. -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. +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. -[[rlog_options]] -.Common options to `git log` +[[log_options]] +.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). +| 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 show 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. +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. -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: +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"`. +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. -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.) +[NOTE] +==== +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 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: +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 -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. +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. -[[rlimit_options]] -.Options to limit the output of `git log` +[[limit_options]] +.Opzioni per limitare l'output di `git log` [cols="2,4",options="header"] |================================ -| Option | Description -| `-(n)` | 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 and were not merges in the month of October 2008, 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] ---- -$ 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 @@ -286,4 +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] +.Evitare di visualizzare le commit di fusione (merge) +==== +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`. +==== 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. + diff --git a/status.json b/status.json index edb0cf8..07e0c78 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": 100, "sections/help.asc": 100, "sections/history.asc": 100, - "sections/installing.asc": 100 + "sections/installing.asc": 100, + "sections/what-is-git.asc": 100 }, "02-git-basics": { "1-git-basics.asc": 1,