Git branch strategy per small dev team

Abbiamo un’app Web che aggiorniamo e rilasciamo quasi quotidianamente. Usiamo git come VCS, e la nostra attuale strategia di branching è molto semplice e rotta: abbiamo un master branch e controlliamo i cambiamenti su cui ci sentiamo “bene”. Funziona, ma solo fino a quando non si verifica un cambio di rottura.

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

  1. Funziona bene per team di 2 o 3 sviluppatori
  2. Leggero e non troppo processo
  3. Consente agli sviluppatori di isolare facilmente il lavoro su correzioni di bug e funzioni più grandi
  4. Ci consente di mantenere un ramo stabile (per quei momentjs “oh crap” in cui dobbiamo far funzionare i nostri server di produzione)

Idealmente, mi piacerebbe vedere il tuo processo passo-passo per un dev che lavora su un nuovo bug

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

master rappresenta la versione più stabile del tuo progetto e ti sposterai sempre e solo alla produzione da questo ramo.

sviluppo contiene modifiche in corso e potrebbe non essere necessariamente pronto per la produzione.

Dal ramo di sviluppo , si creano rami di argomenti per lavorare su singole funzionalità e correzioni. Una volta che la funzione / correzione è pronta, la si fonde in una fase di sviluppo , a quel punto è ansible verificare come interagisce con le altre sezioni di argomenti in cui i vostri collaboratori si sono fusi. Una volta che lo sviluppo si trova in uno stato stabile, unirlo in master . Deve sempre essere sicuro distribuire in produzione dal master .

Scott descrive questi rami di lunga data come “sili” di codice, in cui il codice in un ramo meno stabile finirà per “laurearsi” in uno considerato più stabile dopo il test e l’approvazione generale da parte del team.

Passo dopo passo, il tuo stream di lavoro sotto questo modello potrebbe assomigliare a questo:

  1. Devi correggere un bug.
  2. Creare un ramo chiamato myfix basato sul ramo di sviluppo .
  3. Lavora sull’errore in questo ramo argomento fino a quando non viene corretto.
  4. Unisci myfix in sviluppo . Esegui test.
  5. Scoprirai che la tua correzione è in conflitto con un’altra estensione del topic che il tuo collaboratore si è fuso nello sviluppo mentre stavi lavorando alla tua correzione.
  6. Apporta più modifiche nel ramo myfix per gestire questi conflitti.
  7. Unisci myfix in sviluppo ed esegui nuovamente i test.
  8. Tutto funziona bene Unisci sviluppo in master .
  9. Distribuisci in produzione dal master in qualsiasi momento, perché sai che è stabile.

Per maggiori dettagli su questo stream di lavoro, controlla il capitolo Branching Workflow in Pro Git.

Dopo essere entrato come un novizio cercando di trovare una strategia semplice da 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 utilizzare il stream di lavoro GIT standard che è nelle pagine man ma mi ha confuso leggermente e completamente il mio pubblico.

Negli ultimi 6 mesi ho dovuto risolvere due volte solo i conflitti. Ho aggiunto passaggi per testare sempre dopo l’unione e per “recuperare e unire” o “pull –rebase” molto (una volta al mattino e al pomeriggio) mentre si sviluppano le funzionalità. Abbiamo anche utilizzato github.com come luogo centrale per estrarre il codice più recente.

(Ho fatto il mio commento sopra la propria risposta, come avrei dovuto inizialmente.)

Da Scott Chacon di Github:

Come lo facciamo Quindi, cos’è GitHub Flow?

  • Qualsiasi cosa nel ramo principale è dispiegabile
  • Per lavorare su qualcosa di nuovo, crea un ramo con nome descrittivo dal master (es .: new-oauth2-scope)
  • Impegnarsi in quel ramo localmente e spingere regolarmente il proprio lavoro nello stesso ramo denominato sul server
  • Quando hai bisogno di feedback o aiuto, o pensi che il ramo sia pronto per la fusione, apri una richiesta di pull
  • Dopo che qualcun altro ha esaminato e firmato la funzione, è ansible unirla in master
  • Una volta che è stato unito e trasferito a “master”, è ansible e deve essere distribuito 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 ramo master come ramo di sviluppo e creare rami di rilascio per l’esecuzione di correzioni di bug.

Tutte le nuove funzionalità andranno al master durante la finestra di sviluppo (o direttamente o come rami di argomento con richieste pull, fino a te – non mostrate in grafica). Una volta implementate tutte le funzionalità pianificate, inserire il blocco delle funzioni ed eseguire i test. Quando sei felice, tagga la versione su master come v1.0 .

Nel corso del tempo i tuoi utenti troveranno bug nella v1.0 quindi dovrai creare un ramo da quel tag (ad esempio chiamarlo dopo la versione 1.0 ) e correggere questi bug nel ramo. Quando hai risolto abbastanza bug che pensi che garantisca una nuova versione, v1.0.1 come v1.0.1 e uniscilo nuovamente in master .

Nel frattempo una nuova finestra di sviluppo può accadere sul ramo master che alla fine verrà etichettato 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 è ansible seguire tutti gli sforzi di sviluppo nello stesso momento su un ramo.
Ciò significa che devi sapere quando ramificarti .

Ma in un DVCS (come in VCS “decentralizzato”), hai anche un problema di pubblicazione , con le diramazioni che tieni ai tuoi repository e alle filiali da cui stai spingendo o tirando.

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

  • prod è un ramo pubblico di sola lettura con il codice in produzione. Ognuno potrebbe tirarlo fuori per:
    • rebase il suo attuale sviluppo su di esso (per test locali o per integrare sul repository locale un hotfix fatto nel repository sul ramo prod)
    • ramo per fare nuove funzionalità (da un codice stabile noto)
    • ramo per avviare il prossimo ramo di rilascio (quello che deve essere in produzione)
      nessuno dovrebbe premere direttamente su prod (da cui la sola lettura)
  • release è un ramo di consolidamento in lettura / scrittura, in cui i commit rilevanti vengono selezionati per essere parte della prossima release.
    Tutti possono spingere per rilasciare per aggiornare la prossima versione.
    Tutti possono liberarsi da tale comunicato per aggiornare il proprio processo di consolidamento locale.
  • featureX è un ramo privato di lettura / scrittura (nel senso che non deve essere inviato al repository centrale) e può essere spinto / estratto tra i repository di sviluppo. Rappresenta uno sforzo di medio-lungo termine, diverso dallo sviluppo giornaliero
  • master rappresenta l’attuale dev e viene spinto / estratto tra i repository di sviluppo.

Esistono altri processi di gestione dei rilasci, come attesta questa domanda SO .

Leggi i team di Reinh Git Workflow for Agile qui: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Questo funziona molto bene per le piccole squadre. L’objective qui è quello di assicurarsi che tutto ciò che potrebbe essere potenzialmente instabile vada in un ramo di qualche tipo. Unisci di nuovo al master solo quando sei pronto per l’utilizzo da parte di tutti coloro che lavorano al di fuori del branch di funzionalità.

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