Alla ricerca di buone pratiche sulla gestione di filiali e sviluppatori in Git [duplicato]

1

Io un po 'di tempo fa mi sono unito a un nuovo team di sviluppo e recentemente abbiamo avuto la nostra prima major release. Abbiamo usato Git sin dall'inizio del progetto e ormai ci siamo un po 'a nostro agio. Tuttavia, ora che il prodotto è sul campo, stiamo scoprendo nuovi problemi / processi che devono essere stabiliti. Fino a questo punto, tutto ciò che abbiamo fatto era fare riferimento al popolare post sul modello di branching di successo , che in effetti è stato molto utile

Attualmente abbiamo i seguenti rami, tutti in diretta e tutti in fase di aggiornamento:

  • master - solo codice stabile rilasciato (taggato ogni volta che la versione viene tagliata)
  • sviluppare - completamente aperto. usato per lo sviluppo a lungo termine
  • hotfix-1.0.1 - tag branched master 1.0.0 per piccole correzioni molto mirate che si stanno già allineando
  • release-1.1 - Questa è una piccola versione incrementale che vogliamo spingere relativamente presto, quindi volevamo gestirla separatamente dallo sviluppo e limitare l'ambito delle modifiche.

Queste sono le regole di fusione che stiamo stabilendo:

  1. Se viene effettuato un cambio di codice in release-1.1, deve essere unito per lo sviluppo.
  2. Se viene effettuato un cambio di codice in hotfix-1.0.1, deve essere unito a release-1.1.
  3. Nessuno, ad eccezione di un membro del team, dovrebbe unire qualcosa nel master e quell'unione si verifica solo quando una versione del prodotto sta per essere spedita.

Le mie domande sono:

  1. Quando dovrebbero avvenire le fusioni? Non appena la correzione viene applicata nel ramo di livello inferiore? O periodicamente in blocchi di cambiamenti? Se periodicamente, come si determina in genere il periodo di unione?
  2. Chi dovrebbe fare la fusione? La persona che modifica il codice originale? O un individuo che verrebbe designato come "Direttore dei Servizi Git"?

La ragione per cui sto chiedendo tutto questo è perché sembra che mentre Git è molto flessibile (e io amo quella parte), ti permette anche di spararti facilmente nel piede. Con solo pochi comandi, qualcuno potrebbe facilmente, e si spera non di proposito, unire nuovo sviluppo direttamente nell'hotfix che dovrebbe essere spedito in 2 giorni.

Molti di noi sono nuovi a Git e stiamo ancora provando il modo di aggirare lo strumento. Stavo pensando a come le mie altre società / team hanno gestito tali concetti in passato e penso che la differenza più grande è che la maggior parte degli altri prodotti di controllo di origine che ho usato, funzionano con commit individuali, quindi ogni sviluppatore potrebbe essere responsabile di assicurarsi che le sue correzioni sono applicati ai posti corretti. Ma con Git, quando viene eseguito uno sviluppatore:

git checkout release-1.1
git merge hotfix-1.0.1

... dopo il suo commit, quei comandi finiranno per unire un intero ramo incluso il codice che non ha mai visto prima e potrebbe non essere la persona migliore da risolvere, se ci sono conflitti.

    
posta DXM 24.05.2013 - 21:20
fonte

2 risposte

0

Hai colpito il chiodo sulla testa - git è uno strumento potente. E come qualsiasi altro strumento potente, puoi tagliare la mano con la stessa facilità con cui puoi costruire un piano di lavoro.

Il modo migliore per affrontare questa roba è avere un sistema di integrazione continuo che supporti tutto: ti permetterà di ricevere una notifica quando si verificano dei commit e può fare cose come eseguire la tua suite di test per assicurarti che nessuno abbia rotto nulla. Qual è un problema indipendentemente da quale SCM si sta utilizzando o anche se si sta utilizzando SCM affatto.

    
risposta data 24.05.2013 - 22:00
fonte
0

L'implementazione di un processo di commit e release è un modo per minimizzare i rischi. Per quanto riguarda i rami sbagliati, può essere difficile far rispettare. Ma devi solo gestirlo in modo che le persone capiscano il processo e che non sia troppo difficile. In genere, funzionano solo su un ramo e non devono essere uniti.

Un'altra opzione potrebbe essere quella di aggiungere uno strumento di revisione del codice in modo che le funzionalità siano controllate prima di entrare in produzione.

  • Gerrit - impedisce ai commit di essere tirati fino a quando non sono approvato
  • ReviewBoard - un altro strumento per la revisione del codice, basta rivedere il diff prima di unirsi al ramo di produzione (senza che nessuno effettui effettivamente commit su quel ramo)

La cosa principale è creare un processo semplice e documentato che le persone possano seguire. In genere, sapere chi è il ramo su cui dovrebbero lavorare e designare chi è responsabile della fusione dei rami può aiutare a mantenere le cose semplici.

    
risposta data 24.05.2013 - 22:52
fonte

Leggi altre domande sui tag