Ci sono difetti con questo modello Git Branching?

Per la maggior parte, questo è il solito flusso di lavoro utilizzato con qualsiasi VCS che abbiamo usato finora. Con alcuni (CVS, SVN) è più difficile da fare, con GIT è banale. Detto questo, ho due osservazioni:

In primo luogo, ci sono due scuole di pensiero per quanto riguarda i rami di funzionalità:

1. Unisci loro
2. Rebase loro

(1) è ciò che l'articolo sembra suggerire. Il problema con i commit di unione è il cosiddetto Evil Merges . In particolare, quelli che si uniscono ai percorsi di sviluppo in cui una funzione ha cambiato la semantica in uno dei rami, ma l'unione automatica non riesce a correggere tutte le occorrenze nel codice proveniente dall'altro ramo. Le regressioni introdotte in questo modo sono notoriamente difficili da debugare. Come utente GIT, in genere puoi essere molto più rilassato riguardo alle regressioni, perché hai git bisect per trovare automaticamente le loro cause. Tuttavia, nella situazione descritta, git bisect indicherà il commit di unione, che non ti aiuta affatto.

(2) evita questo problema cercando di mantenere una cronologia il più lineare possibile. I rebase opposti affermano che invalida qualsiasi test che potresti aver fatto prima del rebase.

Personalmente, sono saldamente in campo (2), perché considero la validità di git bisect risultati più della potenziale perdita di copertura del test, che è facilmente compensata utilizzando un adeguato sistema di CI.

In secondo luogo, ho deciso per me che spingere tra sviluppatori è raramente una buona idea. Ci sono problemi di sicurezza nel permettere a chiunque di ssh nella tua casella di recuperare, o eseguire git-deamon localmente, e, cosa più importante, in team non estremamente piccoli, la supervisione può andare persa piuttosto rapidamente.

Detto questo, sono a favore di un repository di staging (a volte chiamato anche scratch ), che consente ai sottogruppi di condividere il loro work-in-progress tramite un server centrale che è, comunque , diverso da quello principale (spesso rivolto verso l'esterno, se non pubblico). In genere, ogni sottoteam mantiene un ramo dell'argomento per sé e un sistema CI esegue periodicamente octopus unisce di tutti i rami degli argomenti in un'unica grande branca di integrazione, lamentando conflitti ed errori di compilazione.

Sono attualmente in procinto di eseguire refactoring di lunga durata (conversione di un'applicazione da un toolkit GUI) ed eseguire un flusso di lavoro basato su rebase di successo, perché gli altri membri del team continuano a lavorare su nuove funzionalità:

Ci sono principalmente due rami principali, il master dove sono sviluppate le nuove funzionalità e il ramo toolkit-conversion . La regola più importante è semplice: fai solo le cose nel ramo toolkit-conversion che sono rilevanti per la conversione. Ogni volta che c'è qualcosa che può essere fatto in master (vecchio toolkit della GUI), lo faccio lì e rebase le mie toolkit-conversion modifiche al nuovo master head. Un'altra regola è mantenere il ramo toolkit-conversion piuttosto breve. Quindi uso spesso reset, cherry-pick e amend-commit e rebase per incollare i commit più piccoli a quelli più grandi (che alla fine hanno lo stesso scopo). Funziona bene anche quando ho provato qualcosa che non ha funzionato bene per "annullare" la modifica o dopo aver rifatto il codice con il codice di aiuto temporaneo.

Ho deciso di non unire le modifiche da master a toolkit-conversion branch, perché renderebbe molto più difficile il rebase dei commit precedenti per mantenere il ramo pulito e facile da controllare. Inoltre, le fusioni potrebbero introdurre conflitti le cui risoluzioni non sono chiare come quando si mantiene una cronologia pulita.

Naturalmente, questo flusso di lavoro ha anche degli svantaggi. Il più importante è che funziona bene solo per una singola persona. Quando spingo forzatamente il ramo toolkit-conversion dopo averlo riposizionato alla testa di master , diventa difficile farlo su un altro repository (il rebasing automatico sul ramo di monitoraggio spesso fallisce con i conflitti).

Alla fine, il mio ramo toolkit-conversion rimane breve, pulito e facile da recensire. Non potevo immaginare di aver fatto questo potente simile con, per esempio, SVN.

Nell'azienda che attualmente sto lavorando, abbiamo applicato una variante di questo stesso modello di ramificazione per un po 'di tempo. Abbiamo anche usato scrum per fare un flusso di lavoro per storia.

L'unico problema che abbiamo avuto fino ad ora è quando il team è abbastanza grande e più di una storia può essere avviata e quelle storie dipendono l'una dall'altra, diventa una specie di confusione per unire le modifiche tra i rami e tornare a master.

Oltre a ciò, questo ha dimostrato di essere affidabile:).

Attualmente sono impegnato ad adattare questo flusso di lavoro. Penso che questo sia un buon flusso di lavoro, perché utilizza il modello di ramificazione in cui git eccelle.

L'unico piccolo svantaggio è che ci vuole un po 'di disciplina nel mantenere questo flusso di lavoro e non cercare di prendere scorciatoie.

Anche gli sviluppatori di kohana usano questo flusso di lavoro e sembrano gradire parecchio.

Do you use this or a similar git branching workflow?

Usiamo un flusso di lavoro simile al lavoro, ma un po 'meno complicato. È comunque molto ispirato da questo flusso di lavoro, dal momento che ho letto questo articolo molte volte. Ho persino il pdf del modello di branching stampato a colori accanto alla mia scrivania:)

Do you consider this a productive approach?

Produttive. Come definisci la produttività? Bene, nella mia mente è più importante avere un'alta qualità, almeno per cercare di ottenere sempre una qualità migliore. Miglioramento costante del processo ecc. Se è possibile produrre codice di qualità, la produttività ne trarrà vantaggio. Quindi la domanda è davvero: questo migliora la qualità del software? E la mia risposta è sicuramente sì.

Ciò che amo di più con questo tipo di modello di ramificazione è che introduce rami in diversi livelli di qualità. Più a destra nella foto, maggiore stabilità e maggiore qualità. Il master branch è sacro e tutti i commit su di esso dovrebbero essere considerati versioni stabili del software. Più a sinistra vai, più sperimentale e più bassa è la stabilità.

Non appena testate nuove funzionalità e correzioni di errori, potete trasferirle gradualmente da sinistra a destra e quindi spostarvi nel codice con alta qualità esattamente quando sapete che il codice soddisfa i requisiti di qualità richiesti dal codice. Bene, almeno in teoria, dal momento che non è possibile testare tutto al 100% e sapere con certezza che il codice non contiene bug, perché avrà sempre bug. Ma ti consente di mantenere un'alta confidenza.

Nulla succhia più come programmatore, che lavorare in un sistema in cui nessuno ha fiducia nel codice, perché sa che fa schifo e che ci sono un sacco di bug in esso.

Do you see any flaws with this approach? Any potential downside?

È importante pensare al modello di ramificazione in modo che si adatti bene alle esigenze della tua organizzazione. Solo perché questo modello funziona bene per alcune persone, non significa necessariamente che sia ottimale o desiderabile per un altro.

Ci sono sempre trade off e anche in questo caso. Un compromesso è il numero di rami rispetto alla complessità. Introducendo molti tipi di rami diversi, si aumenta la complessità del flusso di lavoro. Ad esempio, potrebbe essere semplicemente sbagliato forzare sempre le persone a creare un nuovo ramo di funzionalità, quando stanno cercando di correggere un bug semplice cambiando un paio di righe di codice.

Sappiamo tutti che i bug sono più o meno complicati da risolvere. Quindi, quando viene scoperto un bug insignificante, potresti voler ridurre la complessità e l'amministrazione per eliminare l'overhead aggiuntivo e lasciare che le persone si impegnino direttamente ad es. il master o sviluppare ramo. Ma poiché la natura delle tue correzioni diventa più complicata, vale la pena di aggiungere ulteriori spese generali per creare nuove filiali per loro. Soprattutto se non sei sicuro della dimensione e della lunghezza o se vuoi migliorare la collaborazione tra te e gli altri sviluppatori.

If you have a better approach, would you mind sharing, or providing a link to an article or discussion about it?

Questo è senza dubbio un buon approccio e potrebbe essere adatto alla maggior parte dei casi poiché la maggior parte di noi ha processi di sviluppo simili, ma potrebbe non essere adatto a tutti. Ti esorto vivamente a riflettere su come gestisci il tuo codice in questo momento e provare a creare un modello di ramificazione che si adatti a quello che già possiedi.

Il punto più importante è iniziare con git e il resto seguirà naturalmente. Inizia semplice e migliora gradualmente! Sii creativo!

Saluti