2016-02-27 23 views
8

Sto lavorando in un repository pulito con un solo file. Sono l'unico sviluppatore."Questo ramo è 1 commit avanti, 1 commit dietro master" in Github mentre si utilizza "Un riuscito modello di branching Git"

voglio fare il flusso di lavoro di sviluppare-release-master in A succesful git branching model così ho fatto:

Nota: Si prega di tenere presente che ho l'avanzamento rapido disattivata per impostazione predefinita, in modo da considerare tutti i comandi merge come merge --no-ff.

La mia origine è Github.

In maestro ramo:

git add . 
git commit -m "Initial commit" 
git push origin master 
git checkout -b develop 

In sviluppare ramo. Faccio una modifica al file, quindi:

git add . 
git commit -m "work in the file" 

sono pronto a rilasciare questa come la versione 0,0

git checkout -b release-0.0 develop 

In release-0.0 ramo. Aggiungo un numero di versione al file.

git add .  
git commit -m "Bumped version 0.0" 

Sono pronto per unire questa versione in master.

git checkout master 
git merge release-0.0 -m "Releasing v0.0" 
git tag -a 0.0 -m "Version 0.0" 

... e nello sviluppo.

git checkout develop 
git merge release-0.0 -m "Merge release 0.0 into develop" 

Poi spingo sia maestro e sviluppano di Github

git push origin master 
git push origin develop 

Quando controllo il sviluppare filiale a Github, si dice:

Questo ramo è 1 commit ahead, 1 commit dietro master.

Il maestro ramo non hai un messaggio del genere.

Cosa posso fare per risolvere questo problema? Entrambi master e sviluppo devono essere uguali a questo punto, poiché sono stati uniti entrambi con release-0.0.

risposta

2

No, non sarà uguale, poiché l'avanzamento rapido è disattivato per impostazione predefinita. Ogni unione crea un nuovo commit e il commit di unione ha un ID diverso. Quindi l'unione di commit in master non è l'unione di commit in sviluppo. E quindi sviluppare ha un impegno non nel master mentre il master ha un impegno non in via di sviluppo. Da qui il messaggio in via di sviluppo.

Per quanto riguarda il messaggio che non è presente nel master, è perché il messaggio viene quando un ramo viene confrontato con il master. Quindi, se confronti il ​​master con il master, il messaggio non è necessario.

Una soluzione è quella di abilitare l'avanzamento rapido e creare esplicitamente commit di unione in release e master e quindi mantenere lo sviluppo di forward veloce. L'altra opzione è quella di rebase sviluppare dopo ogni unione da padroneggiare. Il modo in cui vuoi farlo è puramente la tua scelta personale a seconda del tuo flusso di lavoro e del codice.

Anche il messaggio che c'è non è qualcosa di cui dovresti preoccuparti se il codice nei rami è esattamente come desideri.

1

Poiché si utilizza --no-ff ogni singolo sarà un commit diverso. Quando si uniscono relese-0.0 nello sviluppo e nel master, i commit di unione saranno diversi. Ecco come sembra:

commits

Come si può vedere il ramo sviluppare è un commit (Merge rilascio 0.0 in sviluppo) che non è in (non raggiungibile da) il comandante e il ramo principale ha una commit (Releasing v0.0) che non si trova nel ramo di sviluppo. E questo è ciò che gihub dice con quel messaggio ed è completamente soddisfacente (i contenuti sono gli stessi, ma i commit sono diversi).

Se si desidera utilizzare il flusso git, è necessario dare un'occhiata a https://github.com/nvie/gitflow, che sarà di grande aiuto.

+0

OP sta usando gitflow – TheGeorgeous

+0

Sì, volevo solo sottolineare che ci sono script di supporto (di nvie, l'autore del post del blog) per quello che aiuta molto a iniziare. – 1ed

4

solo per aggiungere alle altre risposte:

L'originale git-flow non è stato in sviluppo dal 2012, ed è stata sostituita da git-flow AVH edition in molti luoghi (tra cui il Ubuntu repositories e Git for Windows).

Una delle differenze introdotte dalla edizione AVH è che l'unione finale è quello di maestro * in sviluppare piuttosto che quello di rilascio in sviluppare.

Questo rende maestro un controllante diretta di sviluppare e dovrebbe eliminare una parte del messaggio che si vede; dovrebbe rimanere solo "1 commit ahead". Rende anche leggermente più semplice verificare che il master e lo sviluppo non si siano divisi per caso.

* Più precisamente, è il nuovo tag (sul master) che viene unito allo sviluppo.