La ramificazione può essere considerata una cattiva pratica? [duplicare]

Vorrei strongmente consigliare di eseguire una prova comparativa controllata per scoprire quale sia la via migliore per il tuo progetto invece di sprecare gli sforzi e rovinare la comunicazione di squadra su inutili dibattiti "teorici".

In uno dei miei progetti passati abbiamo perso tempo in quel modo per più di un anno finché non abbiamo deciso di fare una prova di questo tipo. Innanzitutto, lo gestiamo per alcuni mesi, monitorando attentamente il tempo trascorso sulle diramazioni reso il modo "consolidato". Quindi, abbiamo trascorso alcuni mesi a gestire e monitorare l'approccio "alternativo".

Dopo aver completato il nostro confronto, abbiamo semplicemente studiato i risultati del monitoraggio e abbiamo scelto il modo in cui sembrava meno dispendioso (se la memoria serve, abbiamo avuto circa 4 ore a settimana media per sviluppatore utilizzando un modo contro 0.5 per un altro modo). Nessun dibattito, nessun sentimento ferito, solo affari. Le persone ottengono numeri oggettivi, confrontano e prendono decisioni informate, è così semplice.

This will prove difficult... I can't imagine an objective way to reconcile this.

Beh, nel nostro caso non è stato davvero difficile. Probabilmente sembra difficile allo stesso modo in cui è difficile discutere le differenze di approccio alla ramificazione "teoricamente". Quando esegui la versione di prova reale , tutti questi elementi generici magicamente vengono suddivisi in casi d'uso piccoli, concreti e gestibili che sono molto più facili da valutare molto .

Le cose da tenere a mente sono che 1) alcuni mesi menzionati sopra sono stati dimostrati sufficienti per valutare attentamente gli sforzi che si suppone siano correlati all'uno o all'altro approccio e 2) mentre la prova è in esecuzione, è più importante solo scrivere con cura le cose, lasciando che le discussioni su di esso vengano trattate separatamente. Era tipo,

• "trascorso un'ora integrandosi con il cambio di componenti mezzo cotto commesso da John"
  va al ticket con etichetta branching-strategy-1
• "trascorso un'ora a studiare il bug introdotto nel recente ramo di unione da Paul"
  va al ticket con etichetta branching-strategy-2

Alla fine del processo, questi dati sono "estratti" da tracker di problemi , discussi e chiarito. I risultati vengono esportati in Excel, la differenza viene calcolata e la preferenza viene effettuata in base a quello.

È molto importante qui che i membri del team registrino qualcosa che assomiglia a forse , perché se non sono registrati, i dati forse importanti vengono persi. Al contrario, per i dati che è registrati, non è difficile eliminare le cose che sono ritenute irrilevanti in una discussione più approfondita all'analisi retrospettiva.

• ^{... E sì, in il nostro processo abbiamo lasciato alcuni record in quel modo, ... e no, non c'era un acceso dibattito lì, perché 1) si trattava di discutere Casi d'uso reali, concreti, pratici e materiali fino al punto di sentirsi abbastanza strategia agnostica . E poiché 2) la squadra era interessata a trovare il modo in cui salva i nostri sforzi per cose più interessanti piuttosto che in dibattiti religiosi sul fatto che succursale o non ramo .}

Questo in qualche modo ricorda una legge di Postel (aka principio di robustezza ),

be conservative in what you do, be liberal in what you accept from others

Per quanto riguarda le situazioni in cui Branching è una pessima idea , quando abbiamo preparato trial run sopra abbiamo studiato le informazioni disponibili (sommmato in un'altra risposta ai programmatori ) - solo per scoprire se forse possiamo evitare di passare alcuni mesi nell'esecuzione delle prove comparative.

Da ciò che abbiamo appreso allora, la risposta è "dipende dal progetto":

there's no commonly agreed "best" branching strategy applicable to any project

• most resources seem to agree that choosing productive strategy depends on the particular project specifics

• side note. Based on above it looks like any changes to project branching strategy need to be tested, measured and compared to other options tested...

La domanda è terribilmente generale - posso dire, con una certa sicurezza, che ci sono SEMPRE situazioni in cui X è una cattiva idea, non importa quanto sia buona l'idea di X normalmente.

Il tuo collega di lavoro si sta aggrappando a una vista che era NECESSARIA nel corso della giornata, quando non esistevano buoni strumenti di controllo del codice sorgente e di unione. In sostanza, non crede che la fusione possa funzionare giorno per giorno.

Meno di 5 anni fa, ho lavorato con alcune persone che hanno insistito per bloccare le casse (dovevi fare il checkout prima delle modifiche e solo una persona poteva controllare un file alla volta) perché non riuscivano a capire che la fusione era possibile e ha funzionato bene.

La domanda è: perché il tuo collega non crede nella fusione? Ci ho creduto fin da quando l'ho visto funzionare per la prima volta in molte lune di CVS.

La mia ipotesi è che ci sia qualcosa nel modo in cui stai operando che sta causando problemi di fusione, e il tuo collega non può vedere che è possibile a causa di qualche problema operativo nella parte del tuo team. Finché non capisci cosa sia, non lo convincerai mai.

La mia esperienza personale con questo è che la formazione aiuterà in questi casi.

Ho avuto lo stesso problema (con SVN) con i colleghi di lavoro. Dopo aver formato i miei colleghi di lavoro, un gruppo di progetto (di cui non ero membro) si sviluppò solo su rami successivi, mai sul tronco.

La cosa più importante in allenamento è che l'unione (e conflitti durante questo) sono normali e non fanno eccezione. Se i tuoi colleghi perdono la paura di fondersi e di avere conflitti (perché questo è normale), dopo un po 'di tempo la situazione dovrebbe scomparire.

Penso che tu abbia risposto alla tua stessa domanda

we have issues with merging. I argue the root cause of these issues are a lack team
communication and a lack of knowledge on how to correctly use our source control system 
to full effect (TFS).

Se la tua squadra non comunica bene come potrebbe, avere un codice nelle filiali o in piccoli progetti separati non ha molta importanza. Detto questo nei tuoi commenti stai parlando di dare alle persone l'opportunità di saperne di più su questo strumento / opzione, e questa deve essere una buona cosa. Branching è come qualsiasi strumento, può essere davvero utile può anche essere abusato.

Al mio posto attuale non usiamo la ramificazione, non per scelta principalmente perché siamo così piccoli, e ci sono molte altre cose che dobbiamo mettere in atto per prime. Se avessimo una ramificazione, potremmo scrivere più patch, fare più prototipi e unirmi alla base del codice principale.

Penso che Branching potrebbe causare un problema se ignorato e permesso di sfuggire di mano. Come qualsiasi cosa che cresce attraverso i rami, un po 'di potatura non farà alcun danno.

Credo che il nocciolo della questione abbia a che fare con la fusione senza branching. Credo a quali preoccupazioni il tuo supervisore si sta fondendo (il caso più comune così come deriva dalla tua domanda). Questo dopo git ha reso facile unire ("NON CI INTERESSA QUANTO È FACILE DA FILIARE, SOLO QUANTO È FACILE DA FONDERE" - Lunus Torvalds), si è propagato alla maggior parte dei sistemi di controllo versione.

Il cervello non aiuta a regredire alle esperienze precedenti. Sembra che l'ultima volta che il tuo collega ha verificato il problema, le soluzioni disponibili non erano ad un buon livello. Quindi ha escogitato una soluzione alternativa (i mini progetti) e ha dimenticato di controllare di nuovo, diciamo cinque anni dopo. Molto comune, specialmente quando le persone passano al middle management.

Bene, più rami implicano una maggiore complessità. Immagina che il tuo software cresca, che il team cresca, che il tempo passi ... Penso che il problema principale riguardi fusioni e conflitti se i rami iniziano a divergere troppo e le persone lavorano in modo parallelo su di essi.

Esempio stupido: avevamo due grandi rami, con cambiamenti nelle aree sovrapposte, e un ragazzo aveva l'idea super-intelligente di cambiare tutte le schede in spazi sul bagagliaio ... arrrrghh ... la fusione era un incubo. In realtà, lo strumento di fusione non lo ha nemmeno affrontato correttamente, quindi alla fine non ho "unito" migliaia di righe una alla volta a mano.

Inoltre, quando il tempo passa, devi tenere traccia di ciò che è in cosa, quale è ancora attivo, quale no, se qualche ramo rimane inattivo troppo a lungo, diventa più difficile unire, o forse qualcuno dimenticherà una mini-correzione durante la risoluzione di un conflitto, ecc.

Suppongo, alla fine, sia tutta una questione sul giusto equilibrio. Crea un ramo quando è necessario, ma non renderlo "solo per divertimento". Tenderei anche a creare un ramo con Git o Mercurial più facilmente di quanto farei con SVN, sono più facili e flessibili quando si ha a che fare con le filiali, mentre SVN è stato più volte un PITA per me. Quindi penso che dipenda anche da quello che usi ... ma meno rami di solito rendono la vita più facile.

Anche le migliori idee possono essere prese a un estremo ridicolo. Mentre la maggior parte dei sistemi di versioning è in grado di gestire molti rami senza problemi, il problema sarebbe sul lato umano, poiché si finisce per perdersi su quale ramo appartiene a chi, è stato il ramo su cui lavorare in seguito o essere reso inattivo, ecc.