Flusso di lavoro per una forcella Github con modifiche compatibili e incompatibili

6

Ho biforcato un repository Github e aggiunto un telecomando upstream come descritto qui . Mi aspetto di apportare alcune correzioni di bug compatibili con le versioni precedenti per le quali vorrei presentare richieste di pull upstream, oltre a alcune importanti modifiche non compatibili con le versioni precedenti. Questa domanda riguarda come gestire entrambe le cose in un unico repo, o se è anche una buona idea. Ho descritto cosa intendo fare di seguito. Sono molto nuovo a lavorare con le filiali Git, quindi per favore dimmi se questo ha senso.

Modifiche compatibili con le versioni precedenti

Penso che dovrei mantenere origin/master sincronizzato con upstream/master e non unire mai le mie modifiche personali in questo ramo. Creo rami di funzionalità disattivati origin/master per tutte le modifiche che aspetto di inviare a monte. Se vengono accettati, unirò upstream/master in origin/master ed eliminerò i rami.

Modifiche non retrocompatibili

Penso che dovrei creare un ramo separato da origin/master per aggregare tutte le mie modifiche. Questo ramo si chiamerebbe origin/my-version o qualcosa del genere. Unirei i miei rami compatibili con le versioni precedenti in questo ramo senza aspettare che fossero accettati a monte. Lavorerei su modifiche non retrocompatibili nei rami di my-version . Ogni volta che unisco le modifiche upstream in origin/master , rebase my-version sul nuovo origin/master HEAD . Non mi aspetto molti conflitti di unione perché il progetto upstream è maturo e lo sviluppo è lento.

Il mio dubbio principale è se la fusione dei miei rami compatibili con le versioni precedenti in my-version creerà problemi se queste modifiche vengono successivamente accettate a monte e io le unisco in origin/master . Che effetto avrebbe avuto sulla ridefinizione di my-version , se davvero la ridefinizione è ciò che dovrei fare?

    
posta Kevin Krumwiede 20.08.2016 - 23:43
fonte

1 risposta

1

Crea un ramo in cui puoi lavorare per le tue modifiche continue, questo dovrebbe essere ramificato da origin/master .

Crea un altro ramo per le tue ultime modifiche. Questo ramo dovrebbe concettualmente ereditare dal tuo ramo di modifiche non-breaking, che eredita da origin/master

Non fonderti mai dal ramo che si rompe al tuo ramo non-breaking e non fonderti mai dal tuo ramo non-breaking a origin/master

In questo modo, esegui sempre le tue correzioni di bug senza interruzioni in una versione che è in grado di estrarre in modo pulito dalla base di codice originale, e qualsiasi conflitto di fusione che si verifica a causa delle tue modifiche di rottura sarà sempre si verifica nel ramo di break-change, in cui è possibile correggerli senza perdite di codice in upstream.

Per quanto riguarda l'invio delle tue richieste di pull per unire le tue modifiche senza interruzione a monte, crea un repository sul tuo account github own dove premi il tuo ramo non-breaking (completamente unito a origin/master ), e invia una richiesta di pull da quel repo al repository upstream.

Diagramma rapido:

origin/master (pull only) -> non-breaking changes (pull only) -> breaking changes (merge conflicts happen here)

Non spingere mai verso l'alto la catena, mai unire la catena.

    
risposta data 25.08.2016 - 13:21
fonte

Leggi altre domande sui tag