Lo schema di ramificazione a due piani ** prima ** del ramo di sviluppo

Con il controllo della versione distribuita, il modello di ramificazione è solo l'interfaccia pubblica globale al repository centrale. Il codice che consente di in i rami di funzionalità non rientra nello scopo del modello e soddisfa completamente le esigenze individuali in qualsiasi momento. Può coinvolgere un singolo ramo o molti.

Un modello relativamente comune per me è la creazione di un ramo di funzionalità per me stesso, quindi un programmatore di coppia si libera così gli do il permesso di fare push diretto a quel ramo, quindi le altre persone hanno bisogno dei miei cambiamenti in corso per i loro contributi alla funzione , quindi forzano il mio ramo e inviano richieste di pull al mio ramo. Potrebbero a loro volta avere sviluppatori che inviano richieste di pull nella loro filiale, ma dal mio punto di vista non mi interessa. Quando la funzione è completa, unisco master nel mio ramo, quindi invio una richiesta pull più grande, schiacciata o rebasata se lo desideri.

Un altro modello relativamente comune è che creerò un ramo di funzionalità e un altro sviluppatore creerà autonomamente il proprio ramo di funzionalità correlate. Sono rami autonomi, quindi potrebbero essere uniti in master indipendentemente, ma vogliamo assicurarci che le nostre modifiche funzionino insieme, quindi uniamo localmente le filiali degli altri, eseguiamo alcuni test locali, quindi estrai le unioni prima di inviare richieste di pull a master .

Non hai bisogno di formalizzare la comunicazione a quel livello, o fare sempre la stessa cosa, basta adattarti come le esigenze del momento dettano.

Se ricevi molti conflitti, devi unire più spesso, non di meno.

L'idea di gitflow - a quanto ho capito - non è quella di proteggere gli sviluppatori sul ramo di funzione dalle modifiche a develop , ma di mantenere le feature non finite da develop in modo che develop contenga solo funzioni che sono pronto per il rilascio.

Per le funzioni che richiedono più tempo, dovresti unire develop nel tuo branch di funzionalità regolarmente. Se disponi di molte di queste funzioni attive, potrebbe essere necessario unirle trasversalmente. Questo di solito non dovrebbe causare problemi, perché la fusione funziona abbastanza bene in git.

Ora suppongo che potresti aggiungere un ulteriore livello per mantenere le sotto-funzioni non finite fuori dal ramo della funzione. Basta notare che questo potrebbe aumentare notevolmente la quantità di cross-merging che è necessario. Forse è meglio trovare un modo per evitare rami di caratteristiche molto longevi.

Come hai notato tu stesso, molti progetti non utilizzano affatto i rami di funzionalità (= > integrazione / distribuzione continua).