Usare git come repository centrale

Ho impostato git per il mio uso personale, quindi posso accedere a un progetto da 'ovunque' e mantenere la sicurezza della versione se mi capita di lavorare sulla parte X qui e sulla parte Y qui e posso unirmi se necessario.

Tuttavia, solo una delle mie macchine di sviluppo ha un IP statico. Il mio cervello è bloccato in modalità CVS, quindi ho cercato di configurare git in modo che quella macchina fosse il server "centrale", da cui tutti gli altri si avvicinano.

Questo tipo di opere. Ho un sacco di macchine AC che fanno un git-pull dal "master" M. Fanno git push per rispedire i dati.

Il problema sorge se faccio lo sviluppo sul master. In primo luogo, non riesco a capire come ottenere il repository centrale per fornire l'ultima versione senza farlo

git reset --hard HEAD

che sembra un po 'eccessivo. E se eseguo lo sviluppo sulla macchina centrale prima del ripristino, non sono sicuro di come unirlo con le modifiche che sono già state potenziate.

Qualcosa sul mio modello mentale è molto lontano. Aiuto?

Vuoi che il tuo repository centrale sia nudo. Di 'che la macchina su cui vive si chiama static:

$ ssh static git init --bare /git/myproject.git

Questo repository nudo è un punto di incontro centrale: serve per spingere e tirare da, non per lo sviluppo.

Fai il tuo sviluppo sui cloni del repository centrale:

$ cd ~/src
$ git clone static:/git/myproject.git

Anche se sei staticattivo, lavora in un clone:

$ git clone /git/myproject.git

Sebbene tu sia l'unico a lavorare su questo repository, prendi l'abitudine di fare il tuo lavoro su ciò che la documentazione git chiama rami di argomento . Un vantaggio immediato di questo è che mantiene un master pulito , ovvero puoi sempre estrarre dal tuo ramo master centrale nel master del tuo repository locale attuale senza alcuna fusione.

Per esempio:

$ git checkout -b fix-bug-in-foo
$ hack
$ git add file.c file.h
$ git commit -m "Fix ..."

Potrebbe non sembrare un grosso problema, ma ti dà la libertà di lasciare il progetto come rappresentato su quel ramo in uno stato parzialmente cotto, o se la tua bella idea si rivela un flop, puoi facilmente buttare via quel ramo senza rompere qualsiasi altra cosa nel tuo progetto che sta già lavorando su altri rami. Mulligan gratuiti infiniti!

Forse vai a casa quella sera e hai aggiunto una nuova funzionalità. La mattina dopo, tu

$ git checkout master
$ git pull

per aggiornare il tuo master locale per riflettere ciò che è nel repository centrale.

Ma ora dire che hai corretto il bug foo e sei pronto per includerlo nel tuo ramo principale. Per prima cosa vuoi integrarlo con le modifiche di ieri sera:

$ git checkout fix-bug-in-foo
$ git rebase master

Il rebasecomando fa sembrare il tuo repository come se avessi corretto il bug foo in cima alla nuova funzionalità di ieri sera. (Questo è un po 'come svn update, ma più flessibile e potente.)

Ora per farlo entrare nel tuo maestro centrale:

$ git checkout master
$ git merge fix-bug-in-foo
$ git push origin master

Abbiamo trattato il maestro come speciale, ma è solo convenzionale. È possibile condividere il lavoro su diversi rami di repository diversi tramite il repository git staticaltrettanto facilmente.

Se si dispone di un server centrale con un repository git centrale, tale repository dovrebbe essere un barerepository. I repository nudi non contengono copie funzionanti dei file. Di conseguenza, se stai lavorando su quella macchina centrale, non lavori direttamente con il repository centrale, ma con un clone locale.

Questa risposta è simile alla risposta di gbacon , ma adotta un approccio secondo cui si dispone già di un'impostazione di repository locale e si desidera creare un master remoto che viene trattato come un repository centrale. Sta solo aggiungendo dettagli da un approccio diverso.

Uso git per archiviare i miei file dot-config. Spingo e tiro da quello che considero un "repo centrale". È abbastanza conveniente ripristinare tutti i miei file dot attraverso più computer.

$ ssh example.com
$ mkdir dotconf.git && cd dotconf.git
$ git init --bare
$ exit

Ciò ha creato un repository vuoto vuoto nel sito repository.

Ora, se ho già un repository esistente localmente, posso inviarlo al sito remoto.

$ cd ~/src/dotconf

chdir nella directory locale.

$ git remote add origin ssh://example.com/~/dotconf.git

Aggiungi il repository remoto come origine, quindi push / pull agirà su quel repository.

$ git push origin master

Spingi il mio master verso l'origine (come precedentemente etichettato tramite il telecomando git). Ora quel repository remoto viene trattato come il mio "repository centrale". Tutto il mio git push / pull interagirà con l'origine.

Se vado a un altro host, posso facilmente passare tramite clone quel repository in una nuova posizione.

$ git clone ssh://example.com/~/dotconf.git

Se voglio fare lo sviluppo sul server remoto, prima clono, quindi spingo / torno nel repository nudo.

$ cd ~/src
$ git clone ~/dotconf.git
$ cd ~/src/dotconf
  * do coding *
$ git push
  * check in from another location *
$ git pull

Probabilmente dovrai impostare il tuo, git config --add branch.master.remote originquindi git pullnon lamentarti di non essere abbastanza specifico. L'altra alternativa è impostare il ramo master --tracksull'origine remota. Utile se hai più rami.

Oggi stavo solo studiando lo stesso problema. Questo post sul blog parla molto della questione, ma l'opinione della maggioranza è di fare ciò che ha detto Manni. Guarda un commento sul post di David French per alcune altre possibilità, incluso cosa fare se finisci per spingere erroneamente in un repository che ha un lavoro senza commit nell'indice o nell'albero di lavoro. "git reset –soft HEAD ^" annulla la modifica spinta senza disturbare il tuo lavoro.