Strategia Git Branch per piccoli team di sviluppo [chiuso]

Abbiamo un'app Web che aggiorniamo e rilasciamo quasi quotidianamente. Usiamo git come nostro VCS e la nostra attuale strategia di branching è molto semplice e rotta: abbiamo un branch master e controlliamo i cambiamenti di cui "ci sentiamo bene". Funziona, ma solo fino a quando non verificheremo un cambiamento di rottura.

Qualcuno ha una strategia preferita di git branch per piccoli team che soddisfa i seguenti requisiti:

1. Funziona bene per team da 2 a 3 sviluppatori
2. Processo leggero e non troppo
3. Consente agli sviluppatori di isolare facilmente il lavoro su correzioni di bug e funzionalità più grandi
4. Ci consente di mantenere un ramo stabile (per quei momenti "oh merda" in cui dobbiamo far funzionare i nostri server di produzione)

Idealmente, mi piacerebbe vedere il tuo processo passo-passo per uno sviluppatore che sta lavorando a un nuovo bug

Potresti trarre vantaggio dal flusso di lavoro descritto da Scott Chacon in Pro Git . In questo flusso di lavoro, hai due rami che esistono sempre, padroneggiare e sviluppare .

master rappresenta la versione più stabile del progetto e la distribuzione da questo ramo è sempre possibile.

sviluppo contiene modifiche in corso e che potrebbero non essere necessariamente pronte per la produzione.

Dal ramo di sviluppo , si creano rami di argomento per lavorare su singole funzionalità e correzioni. Una volta che la funzione / correzione è pronta per essere utilizzata, la si unisce in Sviluppo , a quel punto è possibile verificare il modo in cui interagisce con altri settori di argomenti in cui i colleghi si sono uniti. Una volta che lo sviluppo è in uno stato stabile, unirlo in Master . Dovrebbe essere sempre sicuro distribuire in produzione dal master .

Scott descrive questi rami di lunga data come "silos" di codice, in cui il codice in un ramo meno stabile alla fine si "diplomherà" in uno considerato più stabile dopo i test e l'approvazione generale da parte del team.

Passo dopo passo, il tuo flusso di lavoro con questo modello potrebbe apparire così:

1. Devi correggere un bug.
2. Crea un ramo chiamato myfix basato sul ramo di sviluppo .
3. Lavora sul bug in questo ramo dell'argomento fino a quando non viene corretto.
4. Unisci myfix in sviluppo . Esegui test.
5. Scoprirai i conflitti della tua correzione con un altro argomento relativo alla sua correzione che il tuo collega si è fuso durante lo sviluppo della tua correzione.
6. Apporta ulteriori modifiche nel ramo myfix per gestire questi conflitti.
7. Unisci myfix per sviluppare ed eseguire nuovamente i test.
8. Tutto funziona bene. Unisci si sviluppa in maestro .
9. Distribuisci in produzione dal master in qualsiasi momento, perché sai che è stabile.

Per maggiori dettagli su questo flusso di lavoro, consulta il capitolo Branching Workflows in Pro Git.

Dopo essere arrivato come un principiante, cerca di trovare una strategia diretta per insegnare ad altri sviluppatori che non hanno mai usato il controllo del codice sorgente. Questo è quello che si adatta a http://nvie.com/posts/a-successful-git-branching-model/ Ho provato a usare il flusso di lavoro GIT standard che è nelle pagine man ma mi ha confuso leggermente e il mio pubblico completamente.

Negli ultimi 6 mesi ho dovuto solo risolvere i conflitti due volte. Ho aggiunto dei passaggi per testare sempre dopo un'unione e per "recuperare e unire" o "pull --rebase" molto (una volta al mattino e al pomeriggio) durante lo sviluppo di funzionalità. Abbiamo anche usato github.com come posto centrale per estrarre l'ultimo codice.

(Il mio commento qui sopra è una risposta personale, come avrei dovuto inizialmente.)

Da Scott Chacon di Github:

Come lo facciamo Quindi, cos'è GitHub Flow?

• Tutto nel ramo principale è distribuibile
• Per lavorare su qualcosa di nuovo, crea un ramo descrittivo del master (ad esempio: new-oauth2-scopes)
• Impegnati in quel ramo localmente e invia regolarmente il tuo lavoro allo stesso ramo sul server
• Quando hai bisogno di feedback o aiuto o pensi che il ramo sia pronto per l'unione, apri una richiesta pull
• Dopo che qualcun altro ha esaminato e sottoscritto la funzionalità, puoi unirla in master
• Una volta che è stato unito e trasferito a "master", puoi e dovresti distribuire immediatamente

Vedi l'intero articolo per maggiori dettagli: http://scottchacon.com/2011/08/31/github-flow.html

Nota che le "richieste pull" sono un'invenzione di Github, ed è qualcosa che viene inserito nel loro sito Web, non Git stesso: https://help.github.com/articles/using-pull-requests/

Utilizzare il masterramo come ramo di sviluppo e creare rami di rilascio per eseguire correzioni di errori.

Tutte le nuove funzionalità verranno attivate masterdurante la finestra di sviluppo (impegnate direttamente o come rami di argomenti con richieste pull, fino a te - non mostrate in figura). Una volta implementate tutte le funzionalità pianificate, immettere il blocco delle funzionalità ed eseguire i test. Quando sei felice, tagga il rilascio mastercome v1.0.

Nel corso del tempo i tuoi utenti troveranno dei bug, v1.0quindi ti consigliamo di creare un ramo da quel tag (es. Nominalo dopo il rilascio 1.0) e correggere quei bug nel ramo. Quando hai risolto un numero sufficiente di bug che ritieni che meriti una nuova versione, taggalo come v1.0.1e uniscilo nuovamente master.

Nel frattempo può succedere una nuova finestra di sviluppo sul masterramo che alla fine verrà taggata come v1.1.

Risciacqua e ripeti.

Ciò segue la logica di numerazione della versione semantica .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

In un VCS, avere solo un ramo "master" mostra rapidamente i suoi limiti perché non è possibile proseguire tutti gli sforzi di sviluppo contemporaneamente su un ramo.
Ciò significa che devi sapere quando diramare .

Ma in un DVCS (come nel VCS "decentralizzato"), hai anche un problema di pubblicazione , con filiali che mantieni localmente nei tuoi archivi e filiali da cui stai spingendo o da cui stai spingendo.

In questo contesto, inizia identificando il tuo sforzo di sviluppo simultaneo e decidi su un processo di pubblicazione (push / pull). Ad esempio (e questo non è l'unico modo):

• prod è una filiale pubblica di sola lettura con il codice in produzione. Tutti potrebbero trarne vantaggio per:
  • rifare il suo sviluppo attuale al di sopra di esso (per i test locali o per l'integrazione nel repository di sviluppo locale un aggiornamento rapido eseguito nel repository di prodotti sul ramo di prodotti)
  • ramo per fare nuove funzionalità (da un codice stabile noto)
  • ramo per avviare il ramo di rilascio successivo (quello che deve essere in produzione)
    nessuno dovrebbe spingere direttamente verso prod (da qui in sola lettura)
• il rilascio è un ramo di consolidamento in lettura e scrittura, in cui i commit rilevanti vengono selezionati in modo da far parte del rilascio successivo.
  Tutti possono spingere per rilasciare per aggiornare la prossima versione.
  Tutti possono trarre da detta versione per aggiornare il proprio processo di consolidamento locale.
• featureX è un ramo privato di lettura-scrittura (in quanto non ha bisogno di essere spinto nel repository di prodotti centrale) e può essere spinto / tirato tra i repository di sviluppo. Rappresenta uno sforzo a medio-lungo termine, diverso dallo sviluppatore quotidiano
• master rappresenta lo sviluppatore corrente e viene spinto / tirato tra i repository di sviluppo.

Esistono altri processi di gestione delle versioni, come attesta questa domanda SO .

Leggi il Reinit's Git Workflow per i team Agile qui: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Questo funziona molto bene per i piccoli team. L'obiettivo qui è quello di assicurarsi che tutto ciò che potrebbe essere potenzialmente instabile rientri in un ramo di qualche tipo. Unisci nuovamente al master solo quando sei pronto per l'utilizzo da parte di tutti coloro che lavorano al di fuori del ramo delle funzionalità.

Nota: questa strategia non è specifica per git, ma git rende l'implementazione di questa strategia piuttosto semplice.