Come organizzare più repository git, in modo che venga eseguito il backup di tutti insieme?

Question

Con SVN, avevo un unico grande repository che tenevo su un server e che effettuavo il check-out su alcune macchine.Questo era un sistema di backup abbastanza buono e mi ha permesso di lavorare facilmente su qualsiasi macchina.Potrei controllare un progetto specifico, impegnarlo e aggiornare il progetto "principale", oppure potrei controllare l'intera cosa.

Ora ho un sacco di repository git, per vari progetti, molti dei quali sono su github.Ho anche il repository SVN di cui ho parlato, importato tramite il comando git-svn..

Fondamentalmente, mi piace avere tutto il mio codice (non solo progetti, ma frammenti e script casuali, alcune cose come il mio CV, articoli che ho scritto, siti web che ho realizzato e così via) in un grande repository che posso facilmente clonare sul telecomando macchine o memory stick/dischi rigidi come backup.

Il problema è che, poiché si tratta di un repository privato e git non consente il check-out da una cartella specifica (che potrei inviare a github come progetto separato, ma le modifiche appaiono sia nel master-repo che nel sub-repo) repository)

IO Potevo usa il sistema di sottomoduli git, ma non funziona come voglio (i sottomoduli sono puntatori ad altri repository e non contengono realmente il codice effettivo, quindi è inutile per il backup)

Attualmente ho una cartella di git-repos (ad esempio, ~/code_projects/proj1/.git/ ~/code_projects/proj2/.git/), e dopo aver apportato modifiche a proj1 lo faccio git push github, quindi copio i file in ~/Documents/code/python/projects/proj1/ ed eseguo un singolo commit (invece dei numerosi nei singoli repository).Quindi fa git push backupdrive1, git push mymemorystick eccetera

Quindi, la domanda:Come funzionano il tuo codice personale e i tuoi progetti con i repository git e come mantenerli sincronizzati e sottoposti a backup?

Answer 1

Vorrei fortemente Consiglio di inserire dati non correlati in un determinato repository Git.Il sovraccarico di creare nuovi repository è piuttosto basso, e questo è un caratteristica Ciò consente di mantenere i lignaggi diversi completamente separati.

Combattere quell'idea significa finire con una storia inutilmente aggrovigliata, che rende l'amministrazione più difficile e-più importante-strumenti "archeologia" meno utili a causa della conseguente diluizione.Inoltre, come hai detto, Git presume che l '"unità di clonazione" sia il repository e praticamente deve farlo a causa della sua natura distribuita.

Una soluzione è mantenere ogni progetto/pacchetto/ecc.come proprio spoglioRepository (cioè, senza albero di lavoro) sotto una gerarchia benedetta, come:

/repos/a.git
/repos/b.git
/repos/c.git

Una volta stabilite alcune convenzioni, diventa banale applicare operazioni amministrative (backup, imballaggio, editoria Web) alla gerarchia completa, che svolge un ruolo non del tutto diverso dai repository SVN "monolitici".Lavorare con questi repository diventa anche in qualche modo simile ai flussi di lavoro SVN, con l'aggiunta che unoPotere utilizzare commit e rami locali:

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

È possibile avere più telecomandi in ogni clone di lavoro, per la facilità di sincronizzazione tra le più parti:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

Puoi quindi prendere/tirare da ciascuna delle "fonti", lavorare e impegnarti a livello locale e quindi spingere ("backup") su ciascuno di questi telecomandi quando sei pronto con qualcosa come (nota come questo spinge il Stesso commit e storia a ciascuno dei telecomandi!):

$ for remote in origin github memorystick; do git push $remote; done

Il modo più semplice per trasformare un repository funzionante esistente ~/dev/fooin un repository così spoglio è probabilmente:

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

che è per lo più equivalente a a svn import-ma non getta via la storia "locale" esistente.

Nota: sottomoduli sono un meccanismo per includere condiviso imparentatolignaggi, quindi in effetti non li considererei uno strumento appropriato per il problema che stai cercando di risolvere.

Answer 2

Voglio aggiungere a La risposta di Damiano dove consiglia:

$ for remote in origin github memorystick; do git push $remote; done

È possibile impostare un telecomando speciale da inviare a tutti i singoli telecomandi reali con 1 comando;L'ho trovato a http://marc.info/?l=git&m=116231242118202&w=2:

Quindi per "Git Push" (dove ha senso spingere gli stessi rami più volte), puoi effettivamente fare quello che faccio:

• .git/config contiene:

  [remote "all"]
  url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
  url = login.osdl.org:linux-2.6.git
  

• e adesso git push all master spingerà il ramo "master" a Entrambi
  di questi repository remoti.

Puoi anche evitare di digitare due volte gli URL utilizzando la costruzione:

[url "<actual url base>"]
    insteadOf = <other url base>

Answer 3

Sono anche curioso di sapere come gestire questa situazione e descriverò l'attuale configurazione che utilizzo (con SVN).Fondamentalmente ho creato un repository che contiene una gerarchia di mini-filesystem che include le proprie directory bin e lib.C'è uno script nella radice di questo albero che configurerà il tuo ambiente per aggiungere questi bin, lib, ecc...altre directory alle variabili di ambiente corrette.Quindi la directory root è essenzialmente simile a:

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

Ora all'interno di /bin e /lib ci sono molteplici progetti e le loro librerie corrispondenti.So che questo non è un progetto standard, ma è molto semplice per qualcun altro nel mio gruppo controllare il repository, eseguire lo script "setup_env.bash" e avere le versioni più aggiornate di tutti i progetti localmente nel proprio guardare.Non devono preoccuparsi di installare/aggiornare /usr/bin o /usr/lib ed è semplice avere più checkout e un ambiente molto localizzato per ogni checkout.Qualcuno può anche semplicemente ripristinare l'intero repository e non preoccuparsi di disinstallare alcun programma.

Per noi funziona bene e non sono sicuro che lo cambieremo.Il problema è che ci sono molti progetti in questo grande repository.Esiste un modo standard git/Hg/bzr per creare un ambiente come questo e suddividere i progetti nei propri repository?

Answer 4

,Non ho ancora provato a annidare i repository git perché non mi sono imbattuto in una situazione in cui ne ho bisogno.Come ho letto su Canale #git git sembra confondersi annidando i repository, ad es.stai provando a eseguire git-init all'interno di un repository git.L'unico modo per gestire una struttura git nidificata è utilizzare entrambi git-submodule o Android repo utilità.

Per quanto riguarda la responsabilità di backup che stai descrivendo, dico delegare Esso...Per quanto mi riguarda, di solito inserisco il repository "origine" per ciascun progetto su un'unità di rete al lavoro di cui viene eseguito regolarmente il backup dai tecnici IT in base alla loro strategia di backup preferita.È semplice e non devo preoccuparmene.;)

Answer 5

Che ne dici di usare Sig per gestire più repository Git contemporaneamente:

Il comando MR (1) può controllare, aggiornare o eseguire altre azioni su un set di repository come se fossero un resochone combinato.Supporta qualsiasi combinazione di sovversione, GIT, CVS, mercuriale, BZR, DARCS, CVS, VCSH, repository fossili e veridici e il supporto per altri sistemi di controllo della revisione può essere facilmente aggiunto.[...]

È estremamente configurabile tramite un semplice script di shell.Alcuni esempi di cose che può fare includono:

[...]

• Quando aggiorni un repository git, estrai da due diversi upstream e unisci i due insieme.
• Esegui diversi aggiornamenti del repository in parallelo, accelerando notevolmente il processo di aggiornamento.
• Ricordare le azioni non riuscite perché un laptop era offline, in modo da poterle ritentare quando torna online.

Answer 6

Esiste un altro metodo per annidare i repository git, ma non risolve il problema che stai cercando.Tuttavia, per gli altri che stanno cercando la soluzione ero:

Nel repository git di livello superiore basta nascondere la cartella in .gitignore contenente il repository git nidificato.Ciò rende facile avere due repository git separati (ma nidificati!).