Gli sviluppatori dovrebbero unire il codice tra le filiali?

Ciò che mi preoccupa è che fai sembrare che chiunque abbia effettuato il check-in del codice debba controllarlo ciecamente a più filiali. Questo è sbagliato. I rami dovrebbero esistere per una ragione. L'evento di verifica del codice dovrebbe avvenire una volta e fluire da lì. Chi lo fa fluire non è così importante come quei rami sono mantenuti significativi e utili in ogni passo.

Mi sembra che tu abbia avuto un approccio migliore in passato. La domanda quindi è: perché è cambiato?

Richiedere a uno sviluppatore di unire il proprio codice in più di 3 rami attivi potrebbe rappresentare un notevole scarto di produttività.

Inoltre, fidarsi di un intero team per essere perfetto con le loro fusioni è una bomba a orologeria. Potrebbe introdurre (o reintrodurre da una vecchia fonte) bug se lo sviluppatore non sta attento con la loro unione.

Uno degli approcci migliori con cui ho lavorato sono i rami basati su attività. Quando viene assegnata un'attività, lo sviluppatore controlla il ramo di gestione temporanea corrente e crea un nuovo ramo attività (con il nome di diramazione come numero di attività). Lo sviluppatore non è responsabile della fusione con altre filiali, ad eccezione del ramo di gestione temporanea una volta terminato lo sviluppo. Le fusioni di ramo di produzione e / o di Versioning vengono gestite separatamente ... e il ramo attività viene unito ai rami Produzione / Versione dopo aver superato UAT.

Quando crei un ramo, sei responsabile di fonderlo nuovamente nello sviluppo. (In realtà, si fonde lo sviluppo nel proprio ramo e si risolvono tutti i problemi, quindi ci dovrebbe essere una revisione del codice, quindi si costruisce una versione per il test, quando viene accettata dai test si fonde nuovamente il ramo di sviluppo nel codice e quindi si unisce in sviluppo senza conflitti).

Tutti sanno che non sono gli unici a lavorare su un progetto. Quindi tutti si aspettano che lo sviluppo cambierà nel momento in cui vogliono unire le loro modifiche allo sviluppo. Sanno cosa stanno facendo, quindi fondono lo sviluppo nel loro ramo e ne sono responsabili.

Alcune persone apparentemente non amano testare una filiale. Beh, non mi piace unire il codice non testato nel ramo di sviluppo e poi testarlo e trovarlo è rotto. Perché nel frattempo qualcuno si è ramificato dal ramo di sviluppo e si sta chiedendo perché il loro codice non funzioni, perché qualcuno lo ha rotto prima ancora che iniziasse a lavorare.

Questo è sicuramente ciò che spicca per me: che stai unendo tutto in tutto. Perché? Molto più standard è avere un ramo di integrazione, e unire rami di caratteristiche individuali in quello. Indica problemi architettonici con il codice - cioè c'è una mancanza di separazione delle preoccupazioni?

A che punto del tuo processo avviene la revisione del codice? Esegui una revisione del codice prima di unire nel bagagliaio? Che ne pensi della revisione del codice prima della fusione tra filiali, nel tuo processo?

In realtà non importa troppo chi fa la fusione, purché tu abbia un processo coerente. L'unione è abbastanza ordinaria quando va liscio. Chiaramente ha più senso di solito per la persona / le persone che hanno scritto il codice per risolvere eventuali conflitti con esso. I conflitti di unione dovrebbero essere rari. Se stai riscontrando conflitti di fusione troppo spesso, significa che i tuoi rami non sono abbastanza indipendenti e / o se li stai lasciando correre troppo a lungo.

Stai cercando di eseguire un albero del codice o un codice a traliccio?

Gli alberi sono meno complessi dei reticoli.

A volte le cose possono diventare un po 'bizzarre con un'unione e devi farlo in modo manuale. Queste stranezze si presentano più spesso con reticoli e sono più difficili da capire. Se non si presta attenzione si possono finire cose come le fusioni circolari (che confondono alcuni strumenti automatici) e le fusioni che finiscono per prendere o in base al codice che non è il più recente.

Puoi eseguire il tuo repository di codice come preferisci, ma ti consiglio di attaccare ad un albero se puoi.

Se ritieni che i tuoi sviluppatori abbiano difficoltà a capire la differenza, allora si ti consiglierei di istruire qualcuno come amministratore di SCM.

Ho visto che funziona dove i rami erano strettamente gerarchici, cioè ci si aspetta che uno sia più stabile dell'ultimo e qualsiasi correzione che va nel ramo più stabile dovrebbe essere unita in tutte le filiali upstream.

I singoli sviluppatori sono responsabili delle fusioni in avanti mentre un'attività periodica viene unita all'indietro. L'attività dopo l'unione localmente esegue i test build + unit e si impegna in caso di successo. Se esiste un conflitto che non può essere risolto automaticamente o che il build / test fallisce, lo sviluppatore con l'ultimo commit è responsabile di sbloccare il processo.

L'attività dovrebbe essere eseguita abbastanza frequentemente (poche ore al massimo ogni giorno) in modo che i rami upstream siano sempre super-set di downstream, evitando troppi conflitti nell'auto-unione.

Non dovresti assolutamente fondere le tue modifiche nel ramo di qualcun altro. La ragione per lavorare in una filiale è avere un ambiente isolato.

Se si apportano modifiche nel ramo su cui si sta lavorando, quindi si notano alcuni comportamenti indesiderati nell'applicazione compilata, è necessario riuscire a capire quale delle modifiche ha causato l'interruzione dell'applicazione. Se altri sviluppatori hanno fuso le loro modifiche nel tuo ramo, qualsiasi delle loro modifiche potrebbe causare il problema, ma non conosci tutti i dettagli di ciò che hanno cambiato e potresti perdere tempo a rintracciare un problema che l'altro sviluppatore ha già trovato e risolto.

Nel mio team di sviluppatori creiamo un ramo "piattaforma" per ogni sprint, quindi ne estraiamo il ramo per ogni storia. Quando le storie sono complete, le uniamo in un ramo di "integrazione". Le modifiche al refactoring vengono eseguite nel ramo "piattaforma" e comunicate ad altri sviluppatori che uniscono queste modifiche nei loro rami della storia quando sono pronti.

Funziona bene perché:

1. Ogni sviluppatore ha il controllo del codice su cui sta lavorando, incorporando solo il refactoring di altri sviluppatori quando è il momento giusto per loro.
2. Esiste un ramo "integrazione" contenente tutte le storie completate che il team addetto al QA può testare durante lo sprint.
3. Alla fine dello sprint possiamo unire il ramo "piattaforma" e i rami della storia per le storie accettate in "master", tralasciando le storie incomplete o non accettate dal prossimo candidato della release.
4. L'unione di storie è facile con pochi conflitti perché il refactoring delle modifiche con impatto diffuso viene eseguito nel ramo "piattaforma" e sono già unite in ciascuna storia.

Dovresti riflettere attentamente su ciò che stai cercando di ottenere e progettare uno schema di ramificazione / fusione che ti aiuti a farlo. Non essere schiavo degli strumenti, fai in modo che gli strumenti funzionino per te.

Dichiarazione di non responsabilità: utilizzo principalmente Git al giorno d'oggi e rilasciamo il nostro prodotto (a differenza dei progetti) una volta all'anno. Quindi, questo potrebbe essere leggermente di parte.

Usiamo le diramazioni in due casi. I rami di funzionalità vengono creati e gestiti da singoli sviluppatori. Possono essere condivisi, ma di solito il creatore lo riassocia al ramo di sviluppo principale dopo l'implementazione della funzione. L'altro tipo di ramo è ciò che chiamiamo rami di rilascio. Quelli sono creati come fork dal ramo di sviluppo e esistono solo per implementare hot fix. Questi rami non si fondono mai più o ricevono una fusione da altri rami. Correzioni di viaggio solo con Cherry-Pick. Lo sviluppatore che ha implementato la correzione è responsabile di farlo.

Questi sono anche i due usi più sensati dei rami a cui riesco a pensare. Molto probabilmente hai un ciclo di sviluppo e bisogni diversi, ma penso che trarrai comunque vantaggio da un approccio simile.

Detto questo, ci sono, naturalmente, altri flussi di lavoro, che usano le filiali in modo ancora diverso ( [1 ] [2] ). Potresti dare un'occhiata anche a quelli.

Un'ultima cosa: se vuoi fare un uso pesante dei rami, scegli prima un SCM con rami leggeri. Ti lascio indovinare quale particolare ho in mente.