Ci sono dei difetti con questo modello di ramificazione Git?

Sto chiedendo di questo modello di ramificazione git o flusso di lavoro. Mi piace molto questo. Mi sembra molto intuitivo e produttivo, ma quello che sto chiedendo è se ci sono difetti o aspetti negativi di questo approccio che non sono ancora chiari per me (provenienti da un altro mondo in cui ClearCase ha dominato la giornata).

(Non è necessario rispondere a tutte le domande, qualunque cosa sia utile è utile)

1. Usi questo o un flusso di lavoro di ramificazione git simile?

2. Consideri questo un approccio produttivo?

3. Vedi qualche difetto con questo approccio? Qualche potenziale svantaggio?

4. Se hai un approccio migliore, ti dispiacerebbe condividere o fornire un collegamento a un articolo o una discussione al riguardo?

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

Innanzitutto, ci sono due scuole di pensiero quando si parla di rami:

1. Uniscili
2. Ricambiarli

(1) è ciò che l'articolo sembra suggerire. Il problema con i merge commit è il cosiddetto Evil Merges . In particolare, quelli che uniscono 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 provenienti dall'altro ramo. Le regressioni introdotte in questo modo sono notoriamente difficili da eseguire il debug. Come utente GIT, di solito puoi essere molto più rilassato sulle regressioni, perché devi git bisecttrovarne automaticamente le cause. Tuttavia, nella situazione descritta, git bisectevidenzierà il commit di unione, che non ti aiuta affatto.

(2) evita questo problema cercando di mantenere una storia il più lineare possibile. Quelle opposizioni ribatte sostengono che invalida qualsiasi test che potresti aver effettuato prima della rebase.

Personalmente, sono fermamente nel campo (2), perché apprezzo la validità dei git bisectrisultati più della potenziale perdita di copertura del test, che è facilmente compensata utilizzando un sistema CI adeguato.

In secondo luogo, ho deciso per me che spingere tra gli sviluppatori è raramente una buona idea. Ci sono problemi di sicurezza nel consentire a tutti di lanciarsi nella tua casella per recuperare, o eseguire git-deamon localmente e, cosa più importante, in squadre non estremamente piccole, la svista può perdersi piuttosto rapidamente.

Detto questo, sono tutti a favore di un repository di gestione temporanea (a volte chiamato anche scratch ), che consente ai sotto-gruppi di condividere i loro lavori in corso tramite un server centrale che è, tuttavia, diverso da quello principale (spesso verso l'esterno- fronte, se non pubblico). In genere, ogni sottogruppo mantiene un ramo tematico per sé e un sistema CI esegue periodiche fusioni di polpi di tutti i rami tematici in un grande ramo di integrazione, lamentandosi dei conflitti e costruendo errori.

Sono attualmente in procinto di eseguire refactoring di grandi dimensioni e di lunga data (conversione di un'applicazione da uno a un altro toolkit GUI) ed eseguire un flusso di lavoro centrato sul rebase, poiché altri membri del team continuano a lavorare su nuove funzionalità:

Esistono principalmente due rami principali, quello in mastercui vengono sviluppate le nuove funzionalità e il toolkit-conversionramo. La regola più importante è semplice: fai solo le cose nel toolkit-conversionramo che sono rilevanti per la conversione. Ogni volta che c'è qualcosa che può essere fatto nel master(vecchio toolkit della GUI), lo faccio lì e ribadisco le mie toolkit-conversionmodifiche alla nuova mastertesta. Un'altra regola è quella di mantenere il toolkit-conversionramo piuttosto corto. Quindi uso spesso reset, cherry-pick e edit-commit e rebase per incollare i commit minori a quelli più grandi (che alla fine hanno lo stesso scopo). Questo funziona bene anche quando ho provato qualcosa che non ha funzionato bene per "annullare" la modifica o dopo che ho refactored un po 'di codice con codice helper temporaneo.

Ho deciso di non unire le modifiche masterin una toolkit-conversionsuccursale, perché renderebbe molto più difficile il rifacimento degli impegni precedenti per mantenere la succursale pulita e facile da rivedere. Inoltre, le fusioni potrebbero introdurre conflitti le cui risoluzioni non sono così chiare come quando si mantiene una cronologia pulita.

Naturalmente, questo flusso di lavoro presenta anche degli svantaggi. Il più importante è che funziona bene solo per una sola persona. toolkit-conversionOgni volta che forzo forzatamente il ramo dopo averlo rimesso in testa master, tirarlo su un altro repository diventa difficile (il riequilibrio automatico sul ramo di monitoraggio spesso fallisce con i conflitti).

Alla fine, il mio toolkit-conversionramo rimane corto, pulito e facile da rivedere. Non potevo immaginare di aver fatto questo potente simile con, ad esempio, SVN.

Nell'azienda che sto attualmente lavorando, abbiamo applicato una variante di questo stesso modello di diramazione per un po '. Abbiamo anche usato Scrum, quindi facciamo un flusso di lavoro per ramo.

L'unico problema che abbiamo avuto finora è quando la squadra è abbastanza grande e più di una storia può essere iniziata e quelle storie sono dipendenti l'una dall'altra, diventa una specie di pasticcio unire i cambiamenti tra i rami e tornare al padrone.

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

Sono attualmente 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 inconveniente è 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 apprezzarlo parecchio.

Usi questo o un flusso di lavoro di ramificazione git simile?

Usiamo un flusso di lavoro simile sul lavoro, ma un po 'meno complicato. È tuttavia fortemente ispirato da questo flusso di lavoro, poiché ho letto questo articolo molte volte. Ho anche il pdf del modello di ramificazione stampato a colori accanto alla mia scrivania :)

Consideri questo un approccio produttivo?

Produttivo. Come si definisce la produttività? Bene, nella mia mente è molto importante avere un'alta qualità, almeno per cercare di ottenere sempre una migliore qualità. Migliorare costantemente il processo, ecc. Se è possibile produrre un codice di qualità, la produttività ne trarrà beneficio. 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 i rami in diversi livelli di qualità. Più a destra nella foto, maggiore stabilità e maggiore qualità. Il ramo principale è santo e tutti i suoi impegni dovrebbero essere considerati versioni stabili del software. Più a sinistra vai, più sperimentale e minore è la stabilità che ottieni.

Non appena si verificano nuove funzionalità e correzioni di bug, è possibile trasferirle gradualmente da sinistra a destra e quindi spostarsi nel codice con alta qualità esattamente quando si sa che il codice soddisfa i requisiti di qualità richiesti dal codice. Beh, almeno in teoria, dal momento che non puoi testare tutto al 100% e sapere con certezza che il codice non contiene alcun bug, perché avrà sempre bug. Ma ti consente di mantenere un'alta fiducia.

Niente fa più schifo come programmatore, che lavorare in un sistema in cui nessuno ha fiducia nel codice, perché sanno che fa schifo e che contiene un sacco di bug.

Vedi qualche difetto con questo approccio? Qualche potenziale svantaggio?

È importante riflettere sul proprio modello di diramazione in modo che si adatti bene alle esigenze della propria organizzazione. Solo perché questo modello funziona bene per alcune persone, non significa necessariamente che sia ottimale o desiderabile per un altro.

Ci sono sempre compromessi e anche in questo caso. Un compromesso è il numero di filiali rispetto alla complessità. Introducendo molti tipi diversi di rami, 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 semplice bug modificando 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 sbarazzarti del sovraccarico extra e lasciare che le persone si impegnino direttamente ad esempio nel master o nello sviluppo del ramo. Ma poiché la natura delle tue correzioni diventa più complicata, vale la pena quel sovraccarico in più per creare nuovi rami per loro. Soprattutto se non si è sicuri delle dimensioni e della lunghezza o se si desidera migliorare la collaborazione tra l'utente e gli altri sviluppatori.

Se hai un approccio migliore, ti dispiacerebbe condividere o fornire un collegamento a un articolo o una discussione al riguardo?

Questo è senza dubbio un buon approccio e potrebbe adattarsi alla maggior parte dei casi poiché la maggior parte di noi ha processi di sviluppo simili, ma potrebbe non essere adatta a tutti. Vi esorto caldamente a riflettere su come gestire il codice in questo momento e provare a creare un modello di diramazione che si adatti a quello che già avete.

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

Saluti