2009-11-19 17 views
5

Sono in una squadra che usa Git in questo momento e abbiamo un buon flusso di lavoro. Abbiamo un repository centrale con due rami, dev e master. Creiamo filiali locali per lavorare su singole attività. Ci uniamo in dev quando sono pronti. Poi ci fondiamo per padroneggiare quando le cose sono pronte e taggliamo tutte le nostre versioni. Se più sviluppatori hanno bisogno di collaborare più direttamente con un compito, possiamo creare un altro ramo remoto, possibilmente temporaneo, con cui condividere le patch. Questo sta funzionando abbastanza bene per noi, ma ci lascia con due problemi.Come gestire i backup e monitorare Git con un repository centrale?

Un problema è il problema dei backup. Certo, viene eseguito il backup della maggior parte della base di codice. Ogni macchina che ha un clone del repository ha la maggior parte del codice. Tuttavia, il codice che qualcuno scrive durante il corso di un giorno non viene eseguito il backup fino a quando non si uniscono a dev e push. Se il compito su cui stanno lavorando non è banale, potrebbero passare giorni prima che qualcosa si unisca e si spinga. Come possiamo assicurarci che questo codice di lavoro in corso sia eseguito il backup in un posto sicuro centrale? Basta usare qualche soluzione di backup esterna a Git?

Il secondo problema è il problema del monitoraggio dei progressi dei dipendenti. I gestori vogliono essere in grado di vedere quale codice gli sviluppatori hanno scritto ogni giorno. Se un giorno va a comprare dove non hai spinto nulla, sembrerà che non hai fatto nulla per tutto il giorno. Abbiamo bisogno di un modo per mostrare il nostro lavoro su base giornaliera che non ci obbliga a commettere e spingere codice che non è pronto per l'impegno, la fusione e la spinta.

Una soluzione che abbiamo considerato è quella di creare un ramo remoto sul repository centrale per ogni singolo ramo locale che creiamo. Probabilmente funzionerebbe, ma sarebbe un disastro ingombrante, anche se eliminassimo regolarmente i vecchi rami inutilizzati. È anche un sacco di lavoro extra per gestire tutto ciò.

Come possiamo soddisfare questi requisiti aziendali senza interrompere il flusso di lavoro Git?

+0

generale trovo il: filiale mentre si lavora su di esso spinta per il backup alla fine della giornata eliminare una volta che avete bisogno di esso più e che è stato incorporato al processo principale ramo funziona bene – Kzqai

+0

Bah, formattato male, ma si ottiene l'idea, facendo uso di tutta quella potenza ramificata in uno schema di denominazione-il modo organizzato è semplice e utile. – Kzqai

risposta

3

Si potrebbe considerare di fare qualcosa di simile. Utilizzare uno spazio dei nomi non di ramo per i backup degli sviluppatori privati. Per esempio. refs/backups/xxx/* dove xxx è l'id utente o iniziali o simile.

Uno sviluppatore può quindi eseguire git push origin +refs/heads/*:refs/backups/xxx/* per eseguire il backup di tutte le sue filiali locali.

Per impostazione predefinita, gli sviluppatori non vedono i rispettivi backup privati, ma se necessario sono recuperabili.

La formula push di backup può essere trasformata in un comando git backup tramite un alias.

Proprio come penso che non sia una buona idea, le filiali private di uno sviluppatore possono essere utilizzate per vedere i suoi "progressi" suona molto come la micro-gestione.

Modifica: Quando lo scrivevo, mi sentivo abbastanza familiare e poi mi sono ricordato perché. Ho scritto qualcosa di simile in risposta ad un'altra domanda qualche tempo fa: link.

+0

Questa è una buona soluzione per i backup. Tuttavia, come può qualcun altro controllare i miei backup? – Apreche

+0

Sì, per noi questa è una 'caratteristica' non un problema. Se si desidera un backup veramente privato, è davvero necessario un repository di backup separato per utente. –

Problemi correlati