2012-05-10 18 views
9

Se TUTTE le filiali GIT create localmente devono essere inviate al repository centrale su base giornaliera? Qual è il flusso di lavoro best-practice in merito?PUSH tutte le filiali GIT locali? La migliore pratica?

Abbiamo creato un repository GIT per gestire il nostro grande sito di e-commerce, in costante sviluppo da parte di un team di grandi dimensioni.

Il repository centrale è "Beanstalk" e abbiamo tre rami principali, "prestaging" (master), "staging" e "production". Tutto lo sviluppo dovrebbe essere fuso in prestadio quando è completato localmente e pronto per essere pubblicato.

Riesco a vedere anche spingere i rami di lungo corso a Beanstalk. Tuttavia, alcuni membri del nostro team sostengono di portare TUTTI i rami di sviluppo locale a Beanstalk su base giornaliera in corso o meno; per creare ridondanza. Penso che questo ingombrerebbe il deposito con centinaia di filiali nel tempo. Qual è la migliore pratica?

risposta

7

Preferisco non inquinare il repository centrale con tutte le filiali di tutti gli utenti di.

non si mescolano:

+0

Grazie a tutti per le ottime risposte e per le ulteriori istruzioni su come eseguire un backup corretto! Questa è la strada che andremo. – Garrick

2

È sempre possibile che l'utente ripulisca i rami remoti quando hanno finito. Non è una cattiva idea farli spingere verso l'alto le loro filiali locali solo per sicurezza (specialmente se non c'è una soluzione di backup sulla loro scatola). Altrimenti se la loro macchina muore, il loro ramo locale non c'è più.

+1

Questa è l'argomentazione avanzata da altri sulla mia squadra. Posso capire da dove vieni ma non sono d'accordo con questo flusso di lavoro. Penso che confondere 'version-control' con 'backup' che sono due compiti separati. Prima del controllo della versione distribuita non avresti mai inviato modifiche a più repository come forma di backup. Se avessimo intenzione di percorrere questa strada, immagineremmo di creare un secondo repository master "funzionante" per contenere questi rami aggiuntivi e chiedere alle persone di chiuderli quando terminati. Non penso che lo faremo comunque. – Garrick

+1

ho votato per la risposta sopra ... Spingo solo cose a distanza quando ho bisogno di condividerle con gli altri –

2

Sono d'accordo con te, l'utilizzo di un repository centrale per il backup del lavoro quotidiano è una cattiva idea. Dovrebbe contenere commit che devono essere condivisi, testati o rilasciati.

Il backup del lavoro giornaliero dovrebbe avvenire a un altro repository, più permissivo, con facoltativamente un'attività automatizzata git push --force --all backup-repo su ogni macchina di sviluppo o uno strumento di backup più classico.

+1

C'è anche 'git push --mirror ' che potrebbe rivelarsi utile per l'attività di "backup" in quanto anche effettua la cancellazione di rami cancellati localmente. – kostix

+0

Buona risposta anche, grazie CharlesB e kostix – Garrick

Problemi correlati