Traduzioni: English - Italiano



Usare Git

Seminario online tenuto da David Paleino per Debian Women, 25-Nov-2010

Questa è una guida introduttiva all'uso di git. Verranno spiegate le basi per capire il suo funzionamento e il suo uso.

Requisiti

In questa guida si presume che:

Requisiti tecnici:

Introduzione

Cos'è git? Git è un sistema di Controllo di versione distribuito. La parte importante è Controllo di versione: significa che è un programma che permette di tenere traccia dei cambiamenti dei file e comparare le differenti "versioni", e fare anche altre cose fantastiche, come tornare indietro a precedenti versioni di un certo file.

Git viene usato da molti progetti software moderni, quindi è bene conoscere almeno un po' del suo funzionamento. Non c'è bisogno di andare molto nei dettagli, verrà spiegato solo il suo funzionamento di base e il suo uso generale.

Teoria

Sistema di controllo di versione ''distribuito''

Noi abbiamo analizzato git come Sistema di Controllo di Versione (VCS), ma git è un VCS distribuito. Distribuito è un dettaglio dell'architettura di git, che ha alcuni pro e alcuni contro. Ci sono altri "sistemi VCS famosi, come CVS e SVN, chiamati VCS centralizzati; questi hanno bisogno di avere una connessione al server centrale, dove sono conservati tutti i dati, per eseguire molte operazioni. Basti pensare al comando log: SVN ha bisogno di connettersi al server e scaricare i dati.

Con i VCS distribuiti (e git è uno di questi) ciò non avviene: ogni copia del repository è una copia completa. Questo significa che le operazione sono più veloci e che, soprattutto, si può usare git sul proprio computer locale, senza avere un server.

Ovviamente anche i VCS distribuiti hanno i loro difetti, il problema principale secondo l'autore di questa guida è il gran numero di conflitti. Questo avviene perché con i VCS centralizzati un commit è di solito rifiutato se determina un conflitto con la copia del server. Invece con i VCS distribuiti, chiunque può eseguire un commit nel suo repository e il conflitto avviene solo al momento del push (il termine "push" verrà spiegato in seguito).

Il modello di immagazzinamento di git

Ogni oggetto all'interno di un repository git è identificato da una stringa univoca. Questa è chiamata hash. Normalmente è una somma SHA1 di alcune proprietà di cui parleremo più tardi.

Un oggetto git può essere un blob, un tree, un commit o un tag. Di seguito le descrizioni di ciascuno di essi.

Se si pensa al modello di immagazzinamento di git, si può distinguere una "area di lavoro", un "indice" e un "repository":

Pratica

Creare un repository

Per la parte pratica, si è preferito usare un progetto reale, anziché inventarsi un repository. Si è scelto di usare "GNU Hello"; il suo archivio tar può essere scaricato da http://ftp.gnu.org/gnu/hello/hello-2.6.tar.gz. In questa guida verrà creato un repository a partire da questo codice sorgente.

Scaricare l'archivio tar:

$ wget http://ftp.gnu.org/gnu/hello/hello-2.6.tar.gz

Una volta fatto, spacchettarlo:

$ tar zxvf hello-2.6.tar.gz

Questo comando creerà la directory hello-2.6/. Adesso si può entrare nella directory ed iniziare a giocare con git :)

Prima di tutto, si deve configurare l'username e l'indirizzo e-mail. Queste informazioni verranno usate nei commit e saranno visibili nella cronologia del repository. Per fare ciò, si usa git config. In particolare, dato che in questo caso si tratta del primo utilizzo, si vuole impostare un username e un indirizzo e-mail in modo globale. Per farlo lanciare i comandi:

$ git config --global user.name "Debian Woman Attendant"
$ git config --global user.email "attendant@debian.org"

Naturalmente usare i propri dati :)

L'opzione --global fa in modo che il cambiamento sia globale, cioè per ogni repository git sul computer i dati verranno scritti in ~/.gitconfig. Controllare questo file, dopo che aver eseguito questi due comandi. Si vedranno le informazioni fornite.

L'username e l'indirizzo e-mail possono anche essere impostati per ciascun repository: in questo caso, lo si deve fare dopo aver creato il repository e senza usare l'opzione --global. Senza --global, le informazioni verranno inserite localmente in ./.git/config.

Sono stati impostati l'username e l'indirizzo e-mail. Ora, si deve creare il repository git. Perciò entrare nella directory hello-2.6/ e lanciare:

$ git init

Il risultato sarà qualcosa di simile a:

Initialized empty Git repository in /tmp/dw/hello-2.6/.git/

git init semplicemente crea una directory .git/, con alcuni valori predefiniti. Per vedere lo stato di un repository, eseguire:

$ git status

Tale comando mostra i file monitorati e non, e lo stato dell'indice. In più, mostrerà in qualche branch si è (i branch verranno spiegati in seguito).

Indicizzazione

Nel repository non c'è ancora nulla. Aggiungere perciò il codice sorgente:

$ git add .

Il "." è una sintassi comune dei sistemi simil-Unix: significa "directory corrente". Perciò di fatto viene aggiunto tutto. Ora, controllare git status di nuovo. Si vedrà che qualcosa è cambiato. Quello che si vede ora è lo stato dell'indice.

Si potrebbe ancora rimuovere elementi dall'indice senza lasciare traccia nella cronologia. Provare a farlo! Rimuovere il file AUTHORS dall'indice e rimetterlo nello stato di "non tracciato":

$ git rm --cached AUTHORS

Ora guardare di nuovo git status. Si vedrà Changes to be committed(cambiamenti di cui si deve fare il commit) (l'indice) e Untracked files (file non tracciati).

Commit

Ora si vuole fare il commit dei file nell'indice: questo creerà un commit, con un hash, e verrà conservato nella cronologia del repository. Eseguire:

$ git commit

Questo comando aprirà l'$EDITOR (quello dell'autore è nano, controllare quale sia il proprio), in cui va scritto un messaggio di commit. Se non ne viene scritto uno, il commit verrà annullato (sì, si deve inserire un messaggio di commit).

Chiamarlo "Commit iniziale". Ora, lanciare di nuovo git status . I file nell'indice sono spariti! Ne è stato fatto il commit all'interno del repository e ne è stato fatto un log.

Se non piace l'editor predefinito di sistema, lo si può impostare per git con:

$ git config --global core.editor emacs

In questo esempio, Git userà emacs quando necessita che l'utente digiti messaggi.

Il log si può vedere con:

$ git log

Verrà mostrato l'autore del commit (con le informazioni inserite prima), la data e l'ora e l'hash del commit.

Si può anche vedere l'ultimo commit con:

$ git show

Aprirà automaticamente il $PAGER (more, less, ...) e mostrerà il contenuto dell'ultimo commit. git show accetta anche un hash come argomento. Per chi scrive l'hash del commit è 11aab8486d20490b16b1b7d847e1cb1e4f7aa2fe . Il valore sarà diverso per ogni lettore che provi a seguire l'esempio. Non è necessario scrivere l'hash completo: normalmente bastano i primi 7 o 8 caratteri. Quindi si può lanciare:

$ git show 11aab848

git supporta anche diversi nomi simbolici, ma non verranno spiegati qui in quanto non argomenti "di base" (ci si riferisce a HEAD, HEAD^, HEAD~2 e così via).

Gli autori (AUTHORS) sono stati lasciati fuori dal repository... poveracci! nessun merito al loro lavoro! Questo problema può essere corretto con:

$ git add AUTHORS
$ git commit -m 'Aggiunti AUTHORS'

-m è una scorciatoia per messaggio: si evita in questo modo di aprire $EDITOR.

Ora, si proverà a modificare alcuni file, guardare le differenze e farne il commit. Fingere di aver scritto un pezzo di codice.

Aggiungere il proprio nome al file AUTHORS :) E aggiungere anche qualcosa al "ChangeLog". Quello che si vuole, è solo un esempio.

Ora usare git status. Si vedranno due righe che iniziano con modified(modificato). Per vedere le differenze introdotte:

$ git diff

(Opzionalmente, git diff nomefile mostrerà solo le differenze in quel file.)

Se queste modifiche vanno bene, fare il commit! È possibile usare git add per ciascun file e fare il commit git commit oppure usare semplicemente:

$ git commit -a -m "Messaggio a piacere"

L'opzione -a aggiungerà tutto all'indice (ma solo i file tracciati, quelli non tracciati non saranno toccati). Si otterrà:

[master 3295347] Messaggio a piacere
2 files changed, 5 insertions(+), 0 deletions(-)

master è il branch in cui si è attualmente. La stringa successiva è l'hash del commit; può essere usata in molti comandi (git show <commit>, git log <commit>, ecc.). Dopo vi è il messaggio di commit e le statistiche dei cambiamenti apportati.

Branch

Cos'è un branch?

Si pensi al repository git come ad un fiume. Ad un certo punto, lo sviluppo può divergere dal "flusso principale" e rimanere per conto suo, oppure unirsi di nuovo al fiume originale. Il master è il fiume principale.

Creare un branch, chiamandolo debian:

$ git branch debian

Per spostarsi in questo nuovo branch, lanciare:

$ git checkout debian

Una scorciatoia per entrambi i comandi è:

$ git checkout -b debian

Perfetto, si è fatto il checkout del branch debian. Per controllare se è vero, eseguire git branch, senza argomenti. Mostrerà i branch locali attuali; quello in cui si è sarà preceduto da un *.

Per tornare indietro al branch principale, eseguire: git checkout master.

Ma per il momento restare nel branch debian: *debian. Si immagini di fare il lavoro di pacchettizzazione all'interno di questo branch.

Quindi, creare una directory debian/. Se è vuota, git status non la mostrerà; è il comportamento atteso: git non tiene traccia delle directory vuote. Per ingannarlo a farlo si può aggiungere un file vuoto alla directory. L'autore normalmente aggiunge un file .gitignore (è un file speciale usato da git), per fare tracciare una directory vuota. Eseguire perciò:

$ mkdir debian
$ touch debian/.gitignore

Ora git status mostrerà la non-tracciata debian/. Aggiungerla e farne il commit.

Tornare ora al branch master

$ git checkout master

Ora si vuole far divergere questi due branch, per simulare un branch reale: cambiare tutti i file che si desidera, in qualunque modo, e farne il commit.

Si può usare un'interfaccia grafica (come ad esempio gitg o gitk) o qualcosa da riga di comando (git show-branch) per vedere come i due branch sono divergenti. Visto che le interfacce grafiche sono facili da usare, verrà usata la riga di comando :D

$ git show-branch

Si vedrà che i due branch hanno un commit inziale in comune, ma poi hanno commit differenti. Unire i cambiamenti di "debian" in "master"

$ git merge debian

Si vedrà qualcosa come:

Merge made by recursive.
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 debian/.gitignore

È in questo momento che avverranno i "conflitti". Se in debian abbiamo cambiato uno dei file cambiati prima del merge, potrebbe essere avvenuto un conflitto.

Potrebbe essere utile eseguire git mergetool dopo il merge, per risolvere i conflitti. Userà uno dei diversi possibili programmi per gestire i conflitti. Non si entrerà qui nei dettagli, per un uso base risolvere i conflitti manualmente è sufficiente.

È stato fatto il merge di debian in master. Guardando i log, si dovrebbe vedere qualcosa come:

commit cdfd20167aa05f74f4785ef7aa03355d51add5b3
Merge: 7e9ff3a 2ba81df
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:45:28 2010 +0100

    Merge branch 'debian'

commit 7e9ff3a18dc114b4ce1e1a96f1dd3ecd696f064d
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:43:49 2010 +0100

    New author

commit 2ba81dfaeb919e6a0c634be54fe363b11487d65a
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:42:42 2010 +0100

    add debian/

commit 3295347b1dbd7b5925dca7fcc6858af51a710ada
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:32:55 2010 +0100

    Messaggio a piacere

commit f6aa148a5ce1331de6d17e770a8efbb98ad32344
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:11:57 2010 +0100

    Aggiunti AUTHORS

commit 11aab8486d20490b16b1b7d847e1cb1e4f7aa2fe
Author: David Paleino <dapal@debian.org>
Date:   Thu Nov 25 23:03:42 2010 +0100

    Commit iniziale

Ripristino

L'ultima cosa da spiegare per quanto riguarda il lavoro in locale è git revert.

Supponiamo di trovare qualcosa che non piace nel git log. Per esempio, diciamo che è il commit 2ba81dfaeb919e6a0c634be54fe363b11487d65a, quello con cui è stata aggiunta la directory debian/. Ci si ricordi che gli hash sono differenti per ciascuna persona, quindi si guardi il log per vedere il proprio.

Dunque, quel commit non piace. Cosa si deve fare ora? Si può usare il comando git revert.

Questo comando prende semplicemente il cambiamento (diff) da un commit, lo applica al contrario e lascia i conflitti, se ce ne sono; provarlo:

$ git revert 2ba81dfaeb919e6a0c634be54fe363b11487d65a

$EDITOR (nano, vim, ecc.) si aprirà di nuovo. C'è un messaggio di commit predefinito; si può lasciarlo così com'è o spiegare (scelta consigliata) perché si stanno annullando i cambiamenti. Per semplicità in questo caso lasciarlo intatto. Salvare il messaggio ed uscire dall'editor.

Si vedrà:

Finished one revert.
[master 37ce99f] Revert "add debian/"
0 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 debian/.gitignore

Questo significa che anche il rispristino è un commit. Con un committer, un autore, una data e un orario ed un hash. Si potrebbe anche ripristinare un ripristino (ma è meglio non farlo).

NOTA: Ripristinare un merge non è semplice. Si deve specificare anche il genitore principale. Si legga la documentazione dell'opzione -m di git revert. Ha anche qualche brutto effetto collaterale (IMHO), quindi non fare nessun merge se non si è assolutamente sicuri.

Lavorare in modo distribuito

Git è un VCS distribuito; perciò quella trattata ora è una parte fondamentale. Permette di condividere il proprio lavoro, e il proprio sviluppo, con altre persone. Si metta perciò da parte il repository.

Usare clone e push

Per questa guida è stato preparato un repository online per i sorgenti di GNU Hello che vengono usati. Questo è normalmente quello che si trova per i progetti esistenti: un repository online. Si può copiare il loro contenuto (clonarli) usando il comando git clone. Clonare quindi il repository, (Ah! prima di farlo, uscire dalla directory hello-2.6/):

$ git clone git://gitorious.org/debian-women/hello.git

Si vedrà qualcosa come:

Cloning into hello...
remote: Counting objects: 263, done.
remote: Compressing objects:  33% (54/16Receiving objects:   6% (16/263), 52.00 remote: Compressing objects:  50% Receiving objects:   9% (24/263), 108.00 KiB |remote: Compressing objReceiving objects:  10% (27/263), 108.00 KiB | 93 KiB/s  remote: Compressing objects: 100% (161/161), done.
remote: Total 263 (delta 101), reused 263 (delta 101)
Receiving objects: 100% (263/263), 626.93 KiB | 120 KiB/s, done.
Resolving deltas: 100% (101/101), done.

Ora, entrare in hello/ e iniziare a curiosare un po' con git log, git show, ...

È un repository pulito, ma è stato preso dal web. Se fosse stato un vero repository, probabilmente non avrebbe mostrato solo un commit, né solo un branch.

Vedere ora da dove è stato preso il repository. Si possono ottenere o impostare informazioni sula fonte da cui è stato preso il repository con git remote. C'è un remote predefinito, chiamato origin. È anche quello predefinito in cui verranno fatti i push. Guardare com'è:

$ git remote show origin

Per ora, solo queste due righe sono interessanti:

Fetch URL: git://gitorious.org/debian-women/hello.git
Push  URL: git://gitorious.org/debian-women/hello.git

Significa che si sta sincronizzando dal "Fetch URL" e si sta facendo il push sul "Push URL". Questi non devono per forza combaciare, possono essere diversi; come, ad esempio, se si sta mantenendo una versione con patch di un software da qualche parte: si prendono i dati dagli autore a monte e si fa il push nella propria posizione.

Si può aggiungere un remote senza rimuovere il lavoro precedente. Per fare questo, si può usare git remote add. La sintassi è la seguente:

git remote add <nome_remoto> <url_remoto>

Di solito, se si vuole essere in grado di fare il push su un repository, si deve usare un url git+ssh:// o ssh://. Un url git://git.[...] normalmente non permette di fare push. (A dire il vero, l'autore di questa guida non ne ha mai visto uno che lo permettesse, ma è meglio usare "normalmente non permette" che "non permette mai".)

git remote add è utile specialmente quando si sta creando un nuovo repository, ovvero quando non si sta clonando da qualche parte.

Domande e risposte

DOMANDA: Un oggetto tree del commit contiene l'intero tree del progetto o solo i file cambiati?

RISPOSTA: Un oggetto tree del commit rappresenta l'intero repository ad un certo punto del tempo, quindi contiene i riferimenti a tutto il tree dell'intero progetto.

DOMANDA: I file vanno nell'indice con: git commit?

RISPOSTA: No, git commit crea un commit che viene inserito nel repository. Ne ho parlato prima, ma questa immagine spiega bene il concetto.

DOMANDA: Se ricopio i file senza la directory .git perdo tutta la cronologia?

RISPOSTA: Sì, la directory .git è quella che che contiene l'intera cronologia, i commit e tutto quanto. Ed è sufficiente una directory .git per ricreare il repository.

DOMANDA: L'indice è nella directory .git?

RISPOSTA: Sì, è conservato lì.

DOMANDA: Il push fallisce se ci sono conflitti? Se è così, questo pro può essere un contro perché un repository condiviso (se usato) sarà sempre in uno stato funzionante.

RISPOSTA: Sì, il push fallisce. È stato detto prima che un maggiore numero di conflitti è uno svantaggio dei VCS distribuiti, ma git permette di risolverli e rifare il push.

Per quanto riguarda "i repository condivisi che funzionano sempre", anche i VCS centralizzati risolvono i conflitti, ma lo fanno in modo automatico. Questo può portare però a soluzioni erronee; git, invece, è un tracciatore di contenuti "stupido" (come dice la parola), quindi chiede aiuto ogni volta che ne ha bisogno. Quindi, mentre un SVN correggerebbe automaticamente gli errori per conto dell'utente, (che non saprà realmente per certo cosa andrà a finire nel repository), in git il push fallisce e l'utente gestisce i conflitti localmente (e dopo rifa il push).

DOMANDA: «Ed è sufficiente una directory .git per ricreare il repository.» : qual è il comando per ricrearla?

RISPOSTA: Si deve semplicemente lanciare git clone dalla directory. Se, per esempio, si ha una directory .git/ di un progetto, basta rinominarla in project.git e dopo lanciare "git clone project.git": ci si ritroverà con la directory project/ con tutto al suo interno. La rinominazione rende tutto più semplice, basterebbe fare git clone .git miaaltradir (e tutto finirà in miaaltradir/)

DOMANDA: Come si possono trovare le impostazioni attuali per l'username e l'e-mail globale? (Se si vogliono solo conoscere le informazioni prima di cambiarle :) ) ~/.gitconfig?

RISPOSTA: Per ottenere un valore specifico si può usare git config --get. Quindi, git config --global --get user.name. Si può anche vedere un elenco di tutti i valori con git config -l e si può modificarli con git config oppure aprendo con un editor ~/.gitconfig o ./.git/config (a seconda se si desidera modificare le impostazioni globali o quelle locali).

DOMANDA: Posso fare una patch al valore di user.name, ecc. all'interno dei file gestiti da git?

RISPOSTA: Sì, si può avere un config separato per ogni repository, basta evitare l'opzione --global. Ma la domanda permette di dare altre risposte: la domanda sembra riferirsi a git filter-branch. Il Committer git è incorporato nell'oggetto Commit (come si è detto ha anche metadati). Quindi, quando si cambia il committer, non si può mantenere lo stesso hash, esso deve cambiare. Quindi opzioni avanzate come filter-branch (che permette di riscrivere la cronologia di un repository) non dovrebbero mai essere usate su repository pubblico, perché significa creare tonnellate di conflitti e mal di testa.

Tuttavia, è interessante vedere come si può temporaneamente sovrascrivere l'username e l'email configurati. git commit può leggere alcune variabili di ambiente: GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME e GIT_AUTHOR_EMAIL. Queste, se impostate, sovrascriveranno quello che c'è in git config. In generale, per ogni variabile di configurazione, git controllerà, in ordine:

~/.gitconfig -> ./.git/config -> variabile d'ambiente, se esiste.

Se si configura qualcosa in ./.git/config, questa sovrascriverà quella globale. Se si configura una variabile d'ambiente GIT_*, essa sovrascriverà tutto.

./.git/config estende ~/.gitconfig. Significa che non si deve copiare tutto il contenuto dalla configurazione globale.

DOMANDA: Come posso ottenere la lista dei file cambiati? git log mostra l'autore, la data e l'ora, il commento ma io non ho bisogno del contenuto dei file (ho solo bisogno del loro elenco).

RISPOSTA: L'elenco dei file modificati in ciascun commit può essere visto con git log --raw. Ogni comando git ha molte opzioni e le pagine man normalmente sono molto utili. Per esempio, è possibile combinare git log con --raw e --pretty, per ottenere un output più carino di quello con solo --raw.

Lo stesso per git show: si può passare una stringa di formattazione a --pretty.

Questo, tuttavia, non è "l'uso di base"; si può usare una GUI, l'autore di questa guida usa gitg a volte.

DOMANDA: Git preserva i permessi dei file di cui tiene traccia o devono essere usati degli stratagemmi?

RISPOSTA: Preserva i permessi e si accorge anche di quando vengono cambiati; un commit, cioè, può anche consistere solamente in un cambio di permessi.

DOMANDA: git show mostra un file enorme. Nessun commento su questo?

RISPOSTA: È così perché è il primo commit dove è stato importato tutto. Di norma è meglio fare commit "atomici". (Si può dire che è la prassi raccomandata.) Quindi di solito, non si vede un output così grosso; comunque usa less in modo predefinito per cui non si dovrebbero avere molti problemi con questo :)

DOMANDA: Posso semplicemente copiare la directory sul mio server web e lasciare che gli altri la clonino usando git clone http://myserver/hello-2.6?

RISPOSTA: Sì, si può. Se non si ha bisogno dei file in quella cartella, è solitamente meglio condividere solamente la directory .git con il nome project.git. Questo viene di solito chiamato "bare repository".

DOMANDA: C'è un modo per semplificare: git add + git commit -m ? O vanno lanciati uno ad uno?

RISPOSTA: Sì, c'è. Se si vuole fare il commit di tutti i file, si può usare l'opzione -a di git commit. Quindi, git commit -a -m "Messaggio" farà il commit di tutto ciò che è già tracciato.

DOMANDA: Una delle cose che mi sembrano strane è avere il repository come parte dell'area di lavoro. È semplice avere un repository in un albero di directory diverso? O è necessario creare repository addizionali?

RISPOSTA: Si può, ma è una modalità di lavoro un po' avanzata. Leggere la sezione core.worktree nella pagina man di git-config.

DOMANDA: Ad esempio io ho un'applicazione web sotto git e voglio usarla senza la directory .git. Qual è il miglio modo per farlo?

RISPOSTA: La risposta è la stessa di prima: impostare esplicitamente core.worktree in ./.git/config ad un percorso differente.

DOMANDA: Ho creato una cartella vuota (test1) ma git status non visualizza niente, quindi ho fatto echo test > test1/testfile e l'output di git status mi restituisce # test1/ ma nessun testfile. È il comportamento atteso?

RISPOSTA: Sì, come è stato detto prima, è stato creato con touch un .gitignore vuoto all'interno di una directory vuota per fare in modo che git la tracci.

DOMANDA: Cosa succede se si annulla un cambiamento su un branch che non è lo stesso che è stato estratto?

RISPOSTA: Non succede niente, cioè il ripristino non avviene.

DOMANDA: Se ho un branch e faccio il merge, ma voglio ripstinarlo, come trovo l'hash?

RISPOSTA: git log è la soluzione.

DOMANDA: L'opzione clone, clona solo il branch master... o anche gli altri?

RISPOSTA: git clone clona solo il branch master. Cioè, gli altri branch verranno scaricati, ma non verrà creato nessun branch locale per loro. Per correggere questa situazione, solitamente l'autore lancia questo comando per ogni branch che mi interessa.

$ git checkout -b miobranch -t origin/miobranch

(-t origin/miobranch significa "traccia miobranch da origin")

DOMANDA: C'è differenza tra git+ssh:// e git://?

RISPOSTA: Sì, c'è. git:// è un "protocollo stupido" e non supporta l'autenticazione. Quindi, nel primo caso, questo protocollo viene incapsulato in SSH: in modo simile a svn+ssh:// o cvs+ssh:// o altri. Nel secondo caso, si sta usando il protocollo git direttamente, senza supporto per l'autenticazione.

DOMANDA: Rettifico la domanda su git+ssh, c'è differenza con ssh?

RISPOSTA: Sì, anche in questo caso ci sono differenze. L'autore è spiacente ma non sa pensare ad un caso pratico. A parte i tecnicismi del protocollo usato e di ciò che il server supporta, non riesce a pensare ad alcuna differenza dal punto di vista dell'utente.

DOMANDA: Quali sono le limitazioni di un repository git in locale clonato con --depth 1, sarò comunque in grado di cambiare branch e invecchiando diventerà un repository meno limitato col passare del tempo e i vari git pull?

RISPOSTA: --depth specifica quanta cronologia ottenere da un repository. Ciò significa che, ad esempio, si è interessati solo alla cronologia recente di un grande progetto; ha anche le sue limitazioni: per esempio, non può essere clonato né si può fare il push da o verso di esso. Per essere sinceri, l'autore non ha mai usato --depth, ha solo letto di questa opzione agli inizi, quando ha iniziato a studiare git.

Vedere anche


CategoryGit