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 ansible 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!

GUI per git

---

Git GUI

Incluso con git – Esegui git gui dalla riga di comando e il programma di installazione di msysgit di Windows lo aggiunge al menu Start.

Git GUI può fare la maggior parte di ciò che dovresti fare con git. Comprese le modifiche dello stage, configurare git e repository, apportare modifiche, creare / checkout / eliminare rami, unire e molte altre cose.

Una delle mie caratteristiche preferite sono le scorciatoie “stage line” e “stage hunk” nel menu di scelta rapida, che consente di commettere parti specifiche di un file. Puoi ottenere lo stesso tramite git add -i , ma trovo che sia più facile da usare.

Non è l’applicazione più carina, ma funziona su quasi tutte le piattaforms (essendo basata su Tcl / Tk)

Screenshots | uno screencast

---

gitk

Incluso anche con git. È un visualizzatore di cronologia git e consente di visualizzare la cronologia di un repository (inclusi i rami, quando vengono creati e uniti). È ansible visualizzare e cercare i commit.

Va bene insieme con git-gui.

---

Gitnub

Applicazione Mac OS X. Principalmente un equivalente di git log , ma ha qualche integrazione con github (come la “Network view”).

Sembra carino e si adatta a Mac OS X. Puoi cercare i repository. La più grande critica di Gitnub è che mostra la storia in modo lineare (un singolo ramo per volta) – non visualizza ramificazioni e fusioni, che possono essere importanti con git, sebbene si tratti di un miglioramento pianificato.

Scarica link, modifica log e screenshot | repository git

---

GitX

Intende essere un “clone di gitk per OS X”.

Può visualizzare la cronologia delle diramazioni non lineari, eseguire commit, visualizzare e ricercare i commit, e ha alcune altre caratteristiche interessanti come essere in grado di “visualizzare rapidamente” qualsiasi file in qualsiasi revisione (premere spazio nella visualizzazione elenco file), esportare qualsiasi file (tramite trascinamento della selezione).

È molto meglio integrato in OS X rispetto a git-gui / gitk ed è veloce e stabile anche con repository eccezionalmente grandi.

Il repository git originale pieter non è stato aggiornato di recente (più di un anno al momento della scrittura). Un ramo più attivo è disponibile su brotherbard / gitx – aggiunge “sidebar, fetch, pull, push, aggiungi remote, merge, cherry-pick, rebase, clone, clone a”

Scarica | Screenshots | repository git | fork di brotherbard | fork laullon

---

SmartGit

Dalla homepage:

SmartGit è un front-end per il sistema di controllo delle versioni distribuite Git e funziona su Windows, Mac OS X e Linux. SmartGit è destinato agli sviluppatori che preferiscono un’interfaccia grafica utente su un client a linea di comando, per essere ancora più produttivo con Git – il più potente DVCS oggi.

Puoi scaricarlo dal loro sito web .

Scaricare

---

TortoiseGit

TortoiseSVN Versione Git per utenti Windows.

Sta portando TortoiseSVN a TortoiseGit L’ultima versione 1.2.1.0 Questa versione può completare attività regolari, come commit, show log, diff due versioni, creare branch e tag, creare patch e così via. Vedi Note di rilascio per i dettagli. Benvenuti a contribuire a questo progetto.

Scaricare

---

qgit

QGit è un visualizzatore GUI git costruito su Qt / C ++.

Con qgit potrai sfogliare la cronologia delle revisioni, visualizzare il contenuto delle patch e i file modificati, seguendo graficamente i diversi rami di sviluppo.

Scaricare

---

gitg

gitg è un visualizzatore di repository git che punta a gtk + / GNOME. Uno dei suoi principali obiettivi è fornire un’esperienza utente unificata per i frontend git su più desktop. Non si tratta di scrivere un’applicazione cross-platform, ma di una stretta collaborazione con client simili per altri sistemi operativi (come GitX per OS X).

Caratteristiche

• Sfoglia la cronologia delle revisioni.
• Gestire repository di grandi dimensioni (carica repository Linux, 17000+ revisioni, in 1 secondo).
• Applica modifiche.
• Metti in scena / metti in scena i singoli pezzi.
• Ripristina le modifiche.
• Mostra la differenza cromatica delle modifiche nelle revisioni.
• Sfoglia l’albero per una determinata revisione.
• Esportare parti dell’albero di una determinata revisione.
• Fornisci qualsiasi refspec che un comando come ‘git log’ possa capire per build la cronologia.
• Mostra e passa tra i rami nella visualizzazione cronologia.

Download: versioni o fonte

---

Gitbox

Gitbox è un’interfaccia grafica per Mac OS X per il sistema di controllo versione Git. In una singola finestra vengono visualizzati i rami, la cronologia e lo stato della directory di lavoro.

Le operazioni di tutti i giorni sono facili: stage e cambiamenti nonstage con una casella di controllo. Impegnati, tira, unisci e spingi con un solo clic. Fare doppio clic su una modifica per mostrare un diff con FileMerge.app.

Scaricare

---

Gity

Il sito Web di Gity non ha molte informazioni, ma dalle schermate in poi sembra essere un OS Git gui open source ricco di funzionalità.

Scarica o fonte

---

meld

La fusione è uno strumento di contrasto e fusione visiva. È ansible confrontare due o tre file e modificarli in posizione (aggiornamento diffs in modo dinamico). È ansible confrontare due o tre cartelle e avviare confronti tra file. È ansible sfogliare e visualizzare una copia di lavoro dai sistemi di controllo delle versioni più diffusi come CVS, Subversion, Bazaar-ng e Mercurial [ e Git ].

download

---

Katana

Una Git GUI per OSX di Steve Dekorte.

A prima vista, guarda quali filiali remote hanno modifiche da eseguire e i repository locali hanno modifiche da spingere. Sono supportati i git op di add, commit, push, pull, tag e reset, nonché le differenze visive e la navigazione visiva della gerarchia del progetto che evidenzia cambiamenti e aggiunte locali.

Gratuito per 1 repository, $ 25 per ulteriori.

Scaricare

---

Sprout (precedentemente GitMac)

Si concentra su come rendere Git facile da usare. Dispone di un’interfaccia utente nativa di Cocoa (mac-like), esplorazione rapida dei repository, clonazione, push / pull, ramificazione / fusione, differenza visiva, diramazioni remote, facile accesso al terminale e altro ancora.

Rendendo le azioni Git più comunemente utilizzate intuitive e facili da eseguire, Sprout (in precedenza GitMac) rende Git facile da usare. Compatibile con la maggior parte dei flussi di lavoro Git, Sprout è ideale per designer e sviluppatori, collaborazione di team e utenti avanzati e principianti.

Scarica | Sito web

---

Torre

Una GUI Git ricca di funzionalità per Mac OSX. 30 giorni di prova gratuita, $ 59 USD per una licenza per utente singolo.

Scarica | Sito web

---

EGit

EGit è un fornitore di Eclipse Team per il sistema di controllo versione Git. Git è un SCM distribuito, il che significa che ogni sviluppatore ha una copia completa di tutta la cronologia di ogni revisione del codice, rendendo le query sulla cronologia molto veloci e versatili.

Il progetto EGit sta implementando gli strumenti Eclipse in aggiunta all’implementazione JGit Java di Git.

Scarica | Sito web

---

Estensioni Git

Open Source per Windows: installa tutto ciò che serve per lavorare con Git in un unico pacchetto, facile da usare.

Git Extensions è un toolkit per rendere più intuitivo il lavoro con Git su Windows. L’estensione della shell si integrerà in Esplora risorse e presenta un menu di scelta rapida su file e directory. C’è anche un plugin di Visual Studio per usare git da Visual Studio.

Scaricare

Mille grazie a dbr per aver elaborato la roba git gui.

---

SourceTree

SourceTree è un client Mac gratuito per Git, Mercurial e SVN. Costruito da Atlassian, la gente dietro BitBucket, sembra funzionare ugualmente bene con qualsiasi sistema VC, che consente di padroneggiare un singolo strumento per l’utilizzo con tutti i tuoi progetti, tuttavia sono controllati dalla versione. Ricco di funzionalità e GRATUITO.

Expert-Ready e ricco di funzionalità per utenti principianti e avanzati:

Rivedi i changeset in uscita e in entrata. Cherry-pick tra i rami. Gestione delle patch, rebase, storage / shelve e molto altro.

Scarica | Sito web

---

Bene, nonostante il fatto che tu abbia chiesto di non “semplicemente” colbind 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 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 syntax 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 object 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 sia la migliore risorsa per ulteriori informazioni.

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 object 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)

Esempio di stream di lavoro con GIT.

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

Questo post sul blog spiega bene un stream 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 stream di lavoro è diventato abbastanza popolare da aver realizzato un progetto che implementa questo stream di lavoro: git-flow

Bella illustrazione di un stream 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 / stream 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 .

Ecco una copia del post di PJ Hyett, in quanto non è più disponibile:

Git non è difficile

23 novembre 2008

Quando diciamo alle persone perché dovrebbero usare Git su Subversion, la linea di partenza è “Git fa Subversion meglio di Subversion, ma fa molto di più”.

Il “molto di più” è composto da un sacco di cose che fanno davvero brillare Git, ma può essere piuttosto travolgente per chi proviene da altri SCM come Subversion.

Detto questo, non c’è nulla che ti impedisca di usare Git proprio come quando usi Transversion mentre stai facendo la transizione.

Supponendo di aver installato il software necessario e di avere un repository remoto da qualche parte, questo è il modo in cui dovresti prendere il codice e reinserire le modifiche con Subversion:

$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"

E come lo faresti in Git:

$ git clone [email protected]:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git push

Ancora un comando per farlo accadere in Git. Quel comando in più ha grandi implicazioni, ma per gli scopi di questo post, questo è tutto ciò di cui stiamo parlando, un comando in più.

Vedi, non è davvero così difficile.

Aggiornamento: Sarei trascurato di non menzionare anche che l’equivalente di aggiornare la tua copia locale in Subversion rispetto a Git è svn update e git pull , rispettivamente. Solo un comando in entrambi i casi.

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 è ansible 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 .

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  

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

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

Come si imposta un repository di team condiviso?

Come impostare un normale repository è descritto qui – 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 

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.

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   # push new commits to the  on the  repository 

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

Come si diramano?

Il ramo predefinito in un repository git è chiamato master .

Per creare un nuovo ramo usa

 git branch  

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

 git branch 

Se si desidera passare a un altro ramo è ansible utilizzare

 git checkout  

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

 git checkout -b  

Per eliminare un ramo, utilizzare

 git branch -d  

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

 git stash git stash branch  

Ottenere il codice più recente

 $ git pull   # fetches the code and merges it into # your working directory $ git fetch   # fetches the code but does not merge # it into your working directory $ git pull --tag   # same as above but fetch tags as well $ git fetch --tag   # you get the idea 

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

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

Git Magic is all you’ll ever need. Guaranteed or your money back!

How do you merge branches?

If you want to merge a branch (eg master to release ), make sure your current branch is the target branch you’d like to merge into (use git branch or git status to see your current branch).

Then use

 git merge master 

(where master is the name of the branch you want to merge with the current branch).

If there are any conflicts, you can use

 git diff 

to see pending conflicts you have to resolve.

I’ve also found Git Internals to be very useful. It is written by Scott Chacon (author of Pro Git, and maintainer of the Git Community Book). What I like about Git Internals is it focuses on the concepts first and then the commands , and being that it is ~100 small pages it is quickly digestible.

How do you see the history of revisions to a file?

 git log -- filename 

How to track remote branches

Assuming there is a remote repository that you cloned your local repository from and also assuming that there is a branch named ‘some_branch’ on that remote repository, here is how to track it locally:

 # 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 

A real good paper for understanding how Git works is The Git Parable . Very recommended!

How do you compare two revisions of a file, or your current file and a previous revision?

Compare command is git diff .

To compare 2 revisions of a file:

 $ git diff    

That diffs commit1 against commit2; if you change order then files are diffed the other way round, which may not be what you expect…

To compare current staged file against the repository:

 $ git diff --staged  

To compare current unstaged file against the repository:

 $ git diff  

Why yet another howto? There are really good ones on the net, like the git guide which is perfect to begin. It has good links including the git book to which one can contribute (hosted on git hub) and which is perfect for this collective task.

On stackoverflow, I would really prefer to see your favorite tricks !

Mine, which I discovered only lately, is git stash , explained here , which enables you to save your current job and go to another branch

EDIT: as the previous post, if you really prefer stackoverlow format with posts as a wiki I will delete this answer

Console UI – Tig

Installation:

 apt-get install tig 

uso

While inside a git repo, type ‘tig’, to view an interactive log, hit ‘enter’ on any log to see more information about it. h for help, which lists the basic functionality.

banalità

“Tig” is “Git” backwards.

How can I create a branch on a remote repository?

Assuming that you have cloned your remote repository from some single remote repository.

 # 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 

I got started with the official Git tutorial . I think it’s practical enough for beginners (I was, and still am, a beginner, by your definition! I barely grasp makefiles, I’ve only played a bit with Apache Subversion, etc.).

How do I delete a branch on a remote repository?

Perform a push in your remote using : before the name of the branch

 git push origin :mybranchname 

being origin the name of your remote and mybranchname the name of the branch about to be deleted

http://help.github.com/remotes/

Push and pull changes

In an simplified way, just do git push and git pull . Changes are merged and if there’s a conflict git will let you know and you can resolve it manually.

When you first push to a remote repository you need to do a git push origin master (master being the master branch). From then on you just do the git push .

Push tags with git push --tags .

Checking Out Code

First go to an empty dir, use “git init” to make it a repository, then clone the remote repo into your own.

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

Wherever you initially clone from is where “git pull” will pull from by default.

Gity: http://macendeavor.com/gity