tag Git per principianti: la guida pratica definitiva




git st (24)

Ok, dopo aver visto questo post di PJ Hyett , ho deciso di saltare fino alla fine e andare con Git .

Quindi quello di cui ho bisogno è una guida pratica per principianti a Git. "Principiante" viene definito come qualcuno che sa come gestire il proprio compilatore, comprende a un certo livello cos'è un Makefile e ha toccato il controllo del codice sorgente senza comprenderlo molto bene.

Si definisce "Pratico" in quanto questa persona non vuole entrare nel dettaglio di ciò che Git sta facendo in background e non si preoccupa (o sa) che è distribuito. Le vostre risposte potrebbero suggerire le possibilità, ma cercare di puntare al principiante che vuole mantenere un repository "principale" su un "server" di cui è stato eseguito il backup e sicuro e trattare il proprio repository locale come una semplice risorsa "client".

Così:

Installazione / Configurazione

Lavorare con il codice

Tagging, branching, releases, baseline

Altro

  • Descrivi e collega a una buona GUI, plug-in IDE, ecc. Che rende Git una risorsa non a riga di comando, ma ti preghiamo di elencarne le limitazioni e le sue caratteristiche.
    • msysgit - Cross platform, incluso con Git
    • msysgit - Visualizzatore cronologico cross platform, incluso con Git
    • msysgit - Mac OS X
    • msysgit - Visualizzatore msysgit Mac OS X
    • msysgit - Cross platform, commerciale, beta
    • tig - console GUI per Linux
    • qgit - GUI per Windows, Linux
    • msysgit - pacchetto per Windows, include un'interfaccia grafica amichevole
  • Qualche altro compito comune che un principiante dovrebbe conoscere?
  • Come posso lavorare efficacemente con un repository di subversion impostato come sorgente di controllo del codice sorgente?

Altri riferimenti per principianti Git

Esplorando in Git

Di tanto in tanto esaminerò le voci e le "sistemeremo" in modo che abbiano un aspetto coerente e sia facile scansionare l'elenco - sentiti libero di seguire un semplice "header" - breve spiegazione - elenco di istruzioni - trucchi e modello "extra info". Collegherò anche le voci dell'elenco puntato qui sopra, quindi è facile trovarle in seguito.


Ho iniziato con il tutorial ufficiale di Git . Penso che sia abbastanza pratico per i principianti (ero, e sono ancora, un principiante, secondo la tua definizione! Ho a malapena afferrato i makefile, ho giocato solo un po 'con Apache Subversion, ecc.).


Come monitorare i rami remoti

Supponendo che ci sia un repository remoto da cui è stato clonato il tuo repository locale e supponendo che ci sia un ramo chiamato "some_branch" su quel repository remoto, ecco come rintracciarlo localmente:

# list remote branches
git branch -r

# start tracking one remote branch
git branch --track some_branch origin/some_branch

# change to the branch locally
git checkout some_branch

# make changes and commit them locally
....

# push your changes to the remote repository:
git push

Applica modifiche

Una volta modificato un file, devi confermare le tue modifiche a git. Quando esegui questo comando ti verrà richiesto un messaggio di commit, che è solo un semplice pezzo di testo che dice a tutti quello che hai cambiato.

$ git commit source/main.c

Configura il file main.c nella directory ./source/

$ git commit -a # the -a flag pulls in all modified files

impegna tutti i file modificati (ma non i nuovi file, quelli che devono essere aggiunti all'indice con git-add). Se vuoi impegnare solo determinati file, dovrai prima metterli in scena con git-add e poi eseguire il commit senza il flag -a.

L'operazione di commit modifica solo il repository locale, ma non i repository remoti. Se si desidera inviare i commit al repository remoto, sarà necessario eseguire una push.

$ git push <remote> <branch> # push new commits to the <branch> on the <remote> repository

Per qualcuno che proviene da CVS o SVN questa è una modifica poiché il commit nel repository centrale richiede ora due passaggi.


Una vera carta per capire come funziona Git è The Git Parable . Molto consigliato!


Come si diramano?

Viene chiamato il ramo predefinito in un repository git master.

Per creare un nuovo ramo usa

git branch <branch-name>

Per visualizzare un elenco di tutti i rami nel tipo di repository corrente

git branch

Se si desidera passare a un altro ramo è possibile utilizzare

git checkout <branch-name>

Per creare un nuovo ramo e passare ad esso in un unico passaggio

git checkout -b <branch-name>

Per eliminare un ramo, utilizzare

git branch -d <branch-name>

Per creare un ramo con le modifiche dal ramo corrente, fallo

git stash
git stash branch <branch-name>

Come configurarlo per ignorare i file:

La possibilità di fare in modo che git ignori i file che non desideri sia tracciabile è molto utile.

Per ignorare un file o un set di file, fornisci un pattern. La sintassi del pattern per git è abbastanza semplice, ma potente. È applicabile a tutti e tre i diversi file che menzionerò qui sotto.

  • Una riga vuota ignora i file, in genere viene utilizzata come separatore.
  • Le righe che iniziano con # servono come commenti.
  • Il ! il prefisso è facoltativo e annullerà il pattern. Qualsiasi schema negato che coincide avrà la precedenza su modelli di precedenza più bassi.
  • Supporta espressioni avanzate e caratteri jolly
    • Es: Il modello: *. [Oa] ignorerà tutti i file nel repository che terminano in .o o .a (file oggetto e archivio)
  • Se un pattern ha una directory che termina con una barra git corrisponderà solo a questa directory e ai percorsi sottostanti. Questo esclude file regolari e collegamenti simbolici dalla partita.
  • Una barra iniziale corrisponderà a tutti i file in quel nome percorso.
    • Es: il pattern /*.c corrisponderà al file foo.c ma non a bar / awesome.c

Ottimo esempio dalla pagina man gitignore(5) :

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

Generalmente ci sono tre modi diversi per ignorare i file non tracciati.

1) Ignora per tutti gli utenti del repository:

Aggiungi un file chiamato .gitignore alla radice della tua copia di lavoro.

Modifica .gitignore per abbinare le tue preferenze per quali file dovrebbero / non dovrebbero essere ignorati.

git add .gitignore 

e commetti quando hai finito.

2) Ignora solo per la tua copia del repository:

Aggiungi / Modifica il file $ GIT_DIR / info / exclude nella tua copia di lavoro, con i tuoi pattern preferiti.

Es: La mia copia di lavoro è ~ / src / project1 quindi dovrei modificare ~ / src / project1 / .git / info / exclude

Hai finito!

3) Ignora in tutte le situazioni, sul tuo sistema:

I pattern di ignoranza globali per il tuo sistema possono essere inseriti in un file con il nome che desideri.

Il mio personalmente si chiama ~ / .gitglobalignore

Posso quindi far sapere a git di questo file modificando il mio file ~ / .gitconfig con la seguente riga:

core.excludesfile = ~/.gitglobalignore

Hai finito!

Trovo che la pagina man di gitignore(5) sia la migliore risorsa per ulteriori informazioni.


Perché ancora un altro howto? Ce ne sono davvero di buoni in rete, come la guida git che è perfetta per iniziare. Ha buoni collegamenti tra cui il git book a cui si può contribuire (ospitato su git hub) e che è perfetto per questo compito collettivo.

Su , preferirei davvero vedere i tuoi trucchi preferiti!

Il mio, che ho scoperto solo ultimamente, è git stash, spiegato here , che ti consente di salvare il tuo lavoro corrente e andare in un altro ramo

EDIT: come il post precedente, se si preferisce davvero il formato stackoverlow con post come wiki cancellerò questa risposta


Come posso creare un ramo su un repository remoto?

Supponendo di aver clonato il repository remoto da qualche singolo repository remoto.

# create a new branch locally
git branch name_of_branch
git checkout name_of_branch
# edit/add/remove files    
# ... 
# Commit your changes locally
git add fileName
git commit -m Message
# push changes and new branch to remote repository:
git push origin name_of_branch:name_of_branch

Console UI - Tig

Installazione:

apt-get install tig

uso

Mentre si trova all'interno di un repository git, digitare "tig" per visualizzare un log interattivo, premere "invio" su qualsiasi registro per visualizzare ulteriori informazioni a riguardo. h per aiuto, che elenca le funzionalità di base.

banalità

"Tig" è "Git" all'indietro.


Come si imposta un repository di team condiviso?

Come impostare un normale repository è descritto here - ma come si imposta un repository di team che tutti possono tirare e spingere da e verso?

Utilizzando un file system NFS condiviso

Supponendo che il tuo team abbia già ad esempio un'iscrizione di gruppo condivisa che può essere utilizzata.

mkdir /your/share/folder/project.git
cd /your/share/folder/project.git
newgrp yourteamgroup # if necessary
git init --bare --shared

Per iniziare a utilizzare questo repository, la cosa più semplice da fare è iniziare da un repository locale che hai già utilizzato:

cd your/local/workspace/project
git remote add origin /your/share/folder/project.git
git push origin master

Altri ora possono clonarlo e iniziare a lavorare:

cd your/local/workspace
git clone /your/share/folder/project.git

Utilizzando SSH

Configurare un account utente sul server di destinazione. Che tu usi un account senza password, un account con una password o usi authorized_keys realtà dipende dal tuo livello di sicurezza richiesto. Dai un'occhiata a Configurazione di Git su SSH per ulteriori informazioni.

Se tutti gli sviluppatori utilizzano lo stesso account per accedere a questo repository condiviso, non è necessario utilizzare l'opzione --shared come sopra.

Dopo aver aperto il repository nello stesso modo come sopra, fai il push iniziale in questo modo:

cd your/local/workspace/project
git remote add origin [email protected]:/path/to/project.git
git push origin master

Vedi la somiglianza con quanto sopra? L'unica cosa che potrebbe accadere in aggiunta è SSH che richiede una password se l'account ha una password. Se si riceve questo messaggio su un account senza password, il server SSH probabilmente ha disabilitato PermitEmptyPasswords .

La clonazione ora si presenta così:

cd your/local/workspace
git clone [email protected]:/path/to/project.git

Come si "etichetta" un particolare insieme di revisioni

Come si fa a "contrassegnare" il "tag" o "rilasciare" un particolare insieme di revisioni per un particolare set di file, in modo da poterlo sempre ritirare in seguito?

Usando il comando git tag .

Per "taggare" semplicemente la revisione corrente, devi solo eseguire ..

git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'

Per elencare i tag correnti, è sufficiente eseguire git tag senza argomenti, o -l (minuscolo L):

$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname

Per eliminare un tag, utilizzare il flag -d :

$ git tag -d thetagname 
Deleted tag 'thetagname'
$ git tag
[no output]

Per taggare un commit specifico (precedente), devi semplicemente farlo ..

git tag [tag name] [revision SHA1 hash]

Per esempio:

git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b

Nota: per impostazione predefinita, git crea un tag "leggero" (in pratica un riferimento a una revisione specifica). Il modo "giusto" è usare la bandiera -a . Questo lancerà il tuo editor chiedendo un messaggio di tag (identico a chiedere un messaggio di commit, puoi anche usare il flag -m per fornire il tag message sulla riga di comando). L'uso di un tag annotato crea un oggetto con il proprio ID, data, tagger (autore) e facoltativamente una firma GPG (utilizzando il tag -s ). Per ulteriori informazioni su questo, vedere questo post

git tag mytagwithmsg -a -m 'This is a tag, with message'

E per elencare i tag con annotazioni, utilizzare il flag -n1 per mostrare una riga di ciascun messaggio di tag ( -n245 per mostrare le prime 245 linee di ogni annotazione e così via):

$ git tag -l -n1
mytagwithmsg    This is a tag, with message

Per ulteriori informazioni, consultare la pagina di manuale di git-tag (1)


Come installare Git

Su Windows:

Installa msysgit

Ci sono diversi download:

  • Git: usalo a meno che tu non abbia bisogno di una delle altre opzioni qui sotto.
  • PortableGit: utilizzare questa opzione se si desidera eseguire Git su un PC senza eseguire l'installazione su quel PC (ad esempio, eseguire Git da un'unità USB)
  • msysGit: usa questo se vuoi sviluppare Git stesso. Se vuoi solo utilizzare Git per il tuo codice sorgente, ma non vuoi modificare il codice sorgente di Git , non hai bisogno di questo.

Questo installa anche una shell bash Cygwin, quindi puoi usare git in una shell più bella (rispetto a cmd.exe), e include anche git-gui (accessibile tramite il comando git gui , o il Start > All Programs > Git )

Mac OS X

Usa git-osx-installer , o puoi anche installare dal sorgente

Tramite un gestore di pacchetti

Installa git usando il tuo gestore di pacchetti nativo. Ad esempio, su Debian (o Ubuntu):

apt-get install git-core

O su Mac OS X, tramite MacPorts :

sudo port install git-core+bash_completion+doc

... o fink:

fink install git

... o Homebrew :

brew install git

Su distribuzioni basate su Red Hat, come Fedora:

yum install git

In Cygwin il pacchetto Git può essere trovato nella sezione "devel"

Dalla fonte (Mac OS X / Linux / BSD / etc.)

In Mac OS X, se hai installato gli Strumenti per sviluppatori, puoi compilare Git dal codice molto facilmente. Scarica l'ultima versione di Git come .tar.bz o .tar.gz da http://git-scm.com/ ed .tar.bz (fai doppio clic nel Finder)

Su Linux / BSD / ecc. dovrebbe essere più o meno lo stesso Ad esempio, in Debian (e Ubuntu), è necessario installare il pacchetto build-essential tramite apt .

Quindi in un terminale, cd in cui hai estratto i file (esecuzione cd ~/Downloads/git*/ dovrebbe funzionare), quindi esegui ..

./configure && make && sudo make install

Questo installerà Git nella posizione predefinita ( /usr/local - quindi git sarà in /usr/local/bin/git )

Ti verrà richiesto di inserire la tua password (per sudo ), in modo che possa scrivere nella /usr/local/ , a cui è possibile accedere solo dall'utente "root", quindi è necessario sudo!

Se devi installarlo da qualche parte separatamente (quindi i file di Git non sono mescolati con altri strumenti), usa --prefix con il comando configure:

./configure --prefix=/usr/local/gitpath
make
sudo make install

Questo installerà il git binary in /usr/local/bin/gitpath/bin/git - così non dovrai /usr/local/bin/gitpath/bin/git ogni volta che dovresti aggiungere al tuo $PATH aggiungendo la seguente riga nel tuo ~/.profile :

export PATH="${PATH}:/usr/local/bin/gitpath/bin/"

Se non hai accesso sudo, puoi usare --prefix=/Users/myusername/bin e installarlo nella tua home directory. Ricorda di aggiungere ~/bin/ a $PATH

Lo script x-git-update-to-latest-version automatizza molto questo:

Questo script aggiorna il mio clone locale del repository git (localy in ~/work/track/git ), quindi configura, installa (in /usr/local/git - git describe ) e aggiorna il link simbolico /usr/local/git .

In questo modo, posso avere /usr/local/git/bin nel mio PATH e sto sempre usando l'ultima versione.

L'ultima versione di questo script installa anche le pagine man. Devi modificare il tuo MANPATH per includere la /usr/local/git/share/man .


Ottenere il codice più recente

$ git pull <remote> <branch> # fetches the code and merges it into 
                             # your working directory
$ git fetch <remote> <branch> # fetches the code but does not merge
                              # it into your working directory

$ git pull --tag <remote> <branch> # same as above but fetch tags as well
$ git fetch --tag <remote> <branch> # you get the idea

Questo copre praticamente ogni caso per ottenere l'ultima copia del codice dal repository remoto.


Git Magic è tutto ciò di cui avrai bisogno. Soddisfatto o rimborsato!


Esempio di flusso di lavoro con GIT.

Git è estremamente flessibile e si adatta bene a qualsiasi flusso di lavoro, ma non imporre un particolare flusso di lavoro potrebbe avere l'effetto negativo di rendere difficile comprendere cosa è possibile fare con git oltre il flusso di lavoro "di backup" lineare e quanto può essere utile la ramificazione .

Questo post sul blog spiega bene un flusso di lavoro molto semplice ma efficace che è davvero facile da configurare usando git.

citando dal post del blog: consideriamo origin / master il ramo principale in cui il codice sorgente di HEAD riflette sempre uno stato pronto per la produzione:

Il flusso di lavoro è diventato abbastanza popolare da aver realizzato un progetto che implementa questo flusso di lavoro: git-flow

Bella illustrazione di un flusso di lavoro semplice, in cui si apportano tutte le modifiche in fase di sviluppo e si esegue il push su master solo quando il codice è in uno stato di produzione:

Ora diciamo che vuoi lavorare su una nuova funzione o sul refactoring di un modulo. Potresti creare un nuovo ramo, quello che potremmo chiamare un ramo "feature", qualcosa che richiederà del tempo e potrebbe rompere il codice. Una volta che la tua funzione è "abbastanza stabile" e vuoi spostarla "più vicina" alla produzione, unisci il tuo ramo di funzionalità per lo sviluppo. Quando tutti i bug vengono risolti dopo l'unione e il tuo codice supera tutti i test in maniera solida, puoi trasferire le tue modifiche in master.

Durante tutto questo processo, trovi un terribile bug di sicurezza, che deve essere risolto subito. Potresti avere un ramo chiamato hotfix, che apporta modifiche più velocemente alla produzione rispetto al normale ramo "sviluppo".

Qui puoi vedere come potrebbe apparire questa funzionalità / hotfix / sviluppo / flusso di lavoro di produzione (ben spiegato nel post del blog, e ripeto, il post sul blog spiega l'intero processo in modo molto più dettagliato e molto meglio di quanto non faccia .


Come si uniscono i rami?

Se si desidera unire un ramo (ad esempio mastera release), assicurarsi che il proprio ramo corrente è il ramo di destinazione che si desidera unire in (uso git brancho git statusdi vedere il vostro ramo corrente).

Quindi utilizzare

git merge master

(dov'è masteril nome del ramo che si desidera unire al ramo corrente).

Se ci sono conflitti, puoi usare

git diff

per vedere i conflitti in sospeso che devi risolvere.


git status è tuo amico, usalo spesso. Buono per rispondere a domande come:

  • Cosa ha fatto quel comando?
  • Quale ramo sono su?
  • Quali cambiamenti sto per commettere e ho dimenticato qualcosa?
  • Ero nel mezzo di qualcosa l'ultima volta che ho lavorato a questo progetto (giorni, settimane o forse mesi fa)?

A differenza, ad esempio, dello svn status , lo svn status git status viene eseguito istantaneamente anche su progetti di grandi dimensioni. L'ho trovato spesso rassicurante mentre imparavo a usare git frequentemente, per assicurarmi che il mio modello mentale di ciò che stava accadendo fosse accurato. Ora lo uso principalmente per ricordare a me stesso cosa sono cambiato dal mio ultimo impegno.

Ovviamente, è molto più utile se il tuo .gitignore è configurato in modo corretto.


Ripristina Git

Dì che fai un tiro, uniscilo nel tuo codice e decidi che non ti piace. Usa git-log o tig e trova l'hash di dove vuoi tornare (probabilmente il tuo ultimo commit prima di pull / merge) copia l'hash, e fai:

# Revert to a previous commit by hash:
git-reset --hard <hash>

Invece dell'hash, puoi usare HEAD ^ come scorciatoia per il commit precedente.

# Revert to previous commit:
git-reset --hard HEAD^

Come confronti due revisioni di un file, o il tuo file attuale e una revisione precedente?

Il comando di confronto è git diff.

Per confrontare 2 revisioni di un file:

$ git diff <commit1> <commit2> <file_name>

Questo differisce da commit1 a commit2; se cambi l'ordine, i file vengono divisi in modo inverso, il che potrebbe non essere quello che ti aspetti ...

Per confrontare il file di staging corrente con il repository:

$ git diff --staged <file_name>

Per confrontare il file nonstartuale corrente con il repository:

$ git diff <file_name>

Codice di controllo

Prima vai su una directory vuota, usa "git init" per renderlo un repository, quindi clona il repository remoto nel tuo.

git clone [email protected]:/dir/to/repo

Ovunque inizialmente cloni sia il punto in cui "git pull" verrà utilizzato per impostazione predefinita.


Come vedi la cronologia delle revisioni in un file?

git log -- filename

Il libro gratuito Pro Git è sicuramente il mio preferito, soprattutto per i principianti.


Bene, nonostante il fatto che tu abbia chiesto di non "semplicemente" collegare ad altre risorse, è piuttosto sciocco quando esiste già una risorsa (in crescita) sviluppata in comunità che è davvero abbastanza buona: il Git Community Book . Seriamente, queste 20+ domande in una domanda saranno tutt'altro che concise e coerenti. Git Community Book è disponibile sia in formato HTML che PDF e risponde a molte delle tue domande con risposte chiare, ben formattate e revisionate e in un formato che ti consente di passare direttamente al tuo problema.

Ahimè, se il mio post ti sconvolge davvero, allora lo cancellerò. Dillo e basta


Come crei un nuovo progetto / repository?

Un repository git è semplicemente una directory contenente una directory .git speciale.

Questo è diverso dai sistemi di controllo di versione "centralizzati" (come subversion), dove un "repository" è ospitato su un server remoto, che si controlla in una directory "copia di lavoro". Con git, la tua copia di lavoro è il repository.

Basta avviare git init nella directory che contiene i file che si desidera tracciare.

Per esempio,

cd ~/code/project001/
git init

Questo crea una cartella .git (nascosta) nella directory corrente.

Per creare un nuovo progetto, git init con un argomento aggiuntivo (il nome della directory da creare):

git init project002

(This is equivalent to: mkdir project002 && cd project002 && git init)

Per verificare se il percorso corrente è all'interno di un repository git, è sufficiente eseguire git status - se non è un repository, segnalerà "fatale: non un repository git"

È anche possibile elencare la directory .git e controllare che contenga file / directory simili al seguente:

$ ls .git
HEAD         config       hooks/       objects/
branches/    description  info/        refs/

Se per qualsiasi motivo desideri "de-git" un repository (vuoi smettere di usare git per tracciare quel progetto). Basta rimuovere la directory .git al livello di base del repository.

cd ~/code/project001/
rm -rf .git/

Attenzione: questo distruggerà tutta la cronologia delle revisioni, tutti i tag, tutto ciò che ha fatto git. Non toccherà i file "correnti" (i file che puoi vedere al momento), ma le modifiche precedenti, i file cancellati e così via non saranno recuperabili!





version-control