Una strategia di fusione come Git Flow è davvero un anti-pattern?

La mia azienda utilizza Git e utilizza uno schema di ramificazione particolare: il lavoro viene svolto in master e le filiali sono riservate alle versioni. Funziona bene, fintanto che tutto il lavoro svolto in un'iterazione arriva al ramo, ma se si presenta un problema di produzione critico, dobbiamo assicurarci che il lavoro lo faccia in qualche modo in entrambi i rami.

Ultimamente, ci siamo divertiti un po 'con quei rami. È stato un mal di testa amministrativo, assicurando che tutto il lavoro lo faccia in ogni ramo, e alcuni bug che sono stati corretti su un ramo non lo fanno diventare padrone fino a quando qualcuno non lo indica, il che è preoccupante.

Mi sono imbattuto in Git Flow qualche tempo fa e ritengo che sarebbe una soluzione al nostro problema: il codice non scorreva fino al rilascio, o fino in fondo. L'unico problema è che il mio esempio ha affermato che questo tipo di sviluppo era un anti-modello - che si sviluppava furiosamente per due settimane, quindi impiegava tre per risolvere i conflitti di unione.

Non sono del tutto sicuro di essere d'accordo, e da quando l'ho sollevato, il lavoro è ripreso come di consueto. Solo di recente abbiamo avuto alcuni importanti punti di dolore con questo.

Mi piacerebbe sapere: perché questo tipo di schema di sviluppo dovrebbe essere visto come un anti-modello? È davvero un anti-pattern?

— Makoto
fonte

La sezione "Regola 3" del vecchio blogpost di Ted Dziuba potrebbe aiutare a illustrare come può essere un anti-schema.

— Isxek,

IMO, più tempo stai spendendo pensando al controllo della versione, più è andato storto tutto l'utente -> fenomeno degli strumenti in primo luogo.

— Erik Reppen,

@ErikReppen: mi piacerebbe allontanare le menti di tutti dal controllo delle versioni e fare in modo che tutti possano abituarsi. In questo modo, non dobbiamo preoccuparci di cose come se questo è un anti-pattern o no.

— Makoto,

@Makoto Tutto ciò che viola KISS è un anti-pattern, IMO. È qui che gli utenti esperti di VCS tendono a farmi impazzire.

— Erik Reppen,

Il termine "antipattern" è un po 'come "best practice", in quanto spesso serve come una scusa per le persone a spegnere il cervello. Non accettare questa nozione se il protagonista non può dirti chiaramente quale esperienza ha e perché è negativa.

— Kyralessa,

Risposte:

Si riferisce principalmente al lato dei rami delle caratteristiche del modello. I rami delle caratteristiche sono stati dichiarati anti-modello molto tempo fa quando i rami sono durati per mesi e i sistemi di controllo della versione non sono riusciti a fondersi per salvare la loro vita. Rami di funzione che durano una settimana o due hanno molto meno problemi, specialmente se si sta continuamente la fusione dal develop al ramo della funzione in quel periodo. Qualcosa di molto più lungo di quello non è ancora raccomandato.

Anche se non usi il lato della diramazione della funzionalità di git flow, le altre parti sono utili per assicurarti che le fusioni siano pulite e che le tue modifiche vengano propagate nella giusta direzione.

— Karl Bielefeldt
fonte

La mia esperienza con i rami delle caratteristiche, o il modo in cui li abbiamo fatti, è che possono esserci angoscia con loro se possono vivere per più di un'iterazione. Una regola che afferma che tutte le funzionalità devono essere unite nell'iterazione prima del rilascio sarebbe utile, per alleviare il mal di cuore delle fusioni - e ragazzo, abbiamo avuto qualche grave mal di cuore dietro quelle ...

— Makoto,

La mia esperienza è che puoi avere roba locale in giro fintanto che la mantieni fusa con il maestro recente o o sviluppi come appropriato.

— Jan Hudec,

@JaHudec ... o finché non ci sono due cose in giro che sono in conflitto in qualche modo. Dovresti sempre avere una visione d'insieme di ciò ...

— Johannes,

Facendo un po 'di lettura su di esso, e il riferimento di Martin Fowler sembra indicare che i rami delle caratteristiche eseguiti in un flusso di integrazione continuo possono funzionare - se sono fatti in morsi più piccoli di quelli che la maggior parte delle persone considererebbe di fare. Quindi, in un certo senso, hai ragione: meno di due settimane come un periodo di vita su un ramo di funzionalità sembra adatto. Non vedo, tuttavia, come gli stessi rami delle caratteristiche siano l'anti-pattern.

— Makoto,

Hai ragione. Sono solo un anti-modello quando vivono troppo a lungo senza essere uniti. A volte le persone si oppongono ancora a un'idea quando non ricordano le ragioni sottostanti.

— Karl Bielefeldt,

La fusione è una cosa divertente: meno frequentemente viene eseguita, più difficile sarà, più difficile sarà, più le persone ne avranno paura, meno frequentemente lo faranno.

La soluzione è o non consentire ai rami di deviare troppo o di non utilizzare i rami.

Se le persone lo capiscono, probabilmente non avrai molti problemi con l'unione, in caso contrario - potrebbero essere rami non sono una buona idea senza un po 'di educazione.

— maxim1000
fonte

No, non usare i rami non è un antipasto. L'altro problema principale sarebbe che il lavoro può essere svolto in due posti diversi nello stesso codice, quindi speriamo di poter fare qualcosa per alleviare anche quello.

— Makoto,

@makoto, abbastanza spesso il disaccoppiamento delle cose nel codice rende i conflitti meno frequenti. Può essere una semplice separazione di una funzionalità in funzioni / classi o più ad alto livello evitando ipotesi non documentate tra i moduli. Quindi le modifiche diventano più localizzate.

— maxim1000,

@ maxim1000 Sono d'accordo. Penso che qualcuno una volta abbia detto qualcosa del tipo "Un VCS è un'alternativa di un uomo povero all'architettura modulare [disaccoppiata"

— 8DH

+1 per il primo paragrafo. E sì, senza istruzione simile a gitflow è un vicolo cieco

— daitangio,