"Dieser Zweig ist 1 Commit voraus, 1 Commit hinter Master" in Github bei der Verwendung von "Ein erfolgreiches Git Verzweigungsmodell"

Question

Ich arbeite in einem sauberen Repo mit nur einer einzigen Datei. Ich bin der einzige Entwickler.

Ich möchte A succesful git branching model die Entwicklung Release-Master-Workflow zu tun, so habe ich:

Hinweis: Bitte beachten Sie, dass ich das Vorspulen standardmäßig deaktiviert haben, so sollten Sie die alle merge Befehle wie merge --no-ff.

Mein Ursprung ist Github.

In Master Zweig:

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

In Zweig entwickeln. Ich mache eine Änderung an der Datei, dann:

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

Ich bin bereit, diese zu lösen als die Version 0,0

git checkout -b release-0.0 develop 

In Release-0.0 Zweig. Ich füge der Datei eine Versionsnummer hinzu.

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

Ich bin bereit, diese Version in Master zusammenzuführen.

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

... und entwickeln.

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

Dann schiebe ich beide Master und entwickeln auf Github

git push origin master 
git push origin develop 

Wenn ich die überprüfen Niederlassung in Github entwickeln, heißt es:

Dieser Zweig ist 1 Commit voraus, 1 Commit hinter Master.

Der Master Zweig hat keine solche Nachricht.

Was kann ich tun, um das Problem zu beheben? Beide Master und entwickeln sollte an dieser Stelle gleich sein, da sie beide mit release-0.0 zusammengeführt wurden.

Answer 1

Nein, es wird nicht gleich sein, da Sie den schnellen Vorlauf standardmäßig deaktiviert haben. Jede Zusammenführung erstellt eine neue Festschreibung und die Zusammenführung hat eine andere ID. Das Merge Commit im Master ist also nicht das Merge Commit in Develop. Und daher entwickelt sich ein Commit nicht im Master, während der Master ein Commit nicht in Entwicklung hat. Daher entwickelt sich die Nachricht.

Die Nachricht, die nicht im Master vorhanden ist, liegt daran, dass die Nachricht kommt, wenn eine Verzweigung mit dem Master verglichen wird. Wenn Sie also Master mit Master vergleichen, ist die Nachricht nicht notwendig.

Eine Lösung besteht darin, Schnellvorlauf zu aktivieren und explizit Merge-Commits in Release und Master zu erstellen und dann die schnelle Weiterleitung zu entwickeln. Die andere Möglichkeit besteht darin, nach jeder Zusammenführung neu zu entwickeln. Wie Sie vorgehen wollen, hängt von Ihrem Workflow und Ihrem Code ab.

Auch die Nachricht, die da ist, ist nicht etwas, um das Sie sich sorgen sollten, solange der Code in den Zweigen genau so ist, wie Sie wollen.

Answer 2

Da Sie --no-ff verwenden, wird jedes einzelne ein anderes Commit sein. Wenn Sie relese-0.0 in Entwicklung und in Master zusammenführen, werden die Zusammenführungs-Commits unterschiedlich sein. Hier ist, wie es aussieht:

Wie Sie den Zweig entwickeln sehen kann, hat einen commit (Merge Release 0.0 in Entwicklung), die nicht in (nicht erreichbar von) der Master und der Master-Zweig hat eine commit (Releasing v0.0), das nicht im Entwicklungszweig ist. Und das sagt Gihub mit dieser Nachricht und es ist völlig in Ordnung (der Inhalt ist der gleiche, aber die Commits unterschiedlich).

Wenn Sie git flow verwenden möchten, sollten Sie einen Blick auf https://github.com/nvie/gitflow werfen, die Ihnen sehr helfen wird.

Answer 3

einfach zu den anderen Antworten hinzuzufügen:

Die ursprüngliche git-flow hat in der Entwicklung seit 2012 nicht gewesen, und es wird von git-flow AVH edition an vielen Stellen (einschließlich der Ubuntu repositories und Git for Windows) abgelöst worden.

Einer der Unterschiede von der AVH Ausgabe eingeführt ist, dass die endgültige Zusammenführung der von Master ist * in entwickeln eher als der Freisetzung in entwickeln.

Dies macht Master ein direkt Eltern von entwickeln und sollen einen Teil der Nachricht, die Sie sehen beseitigen; nur "1 commit ahead" sollte beibehalten werden. Es macht es auch ein wenig leichter zu überprüfen, dass Master und Entwicklung nicht zufällig auseinander gegangen sind.

* Genauer gesagt, es ist das neue Tag (auf Master), die in Entwicklung zusammengeführt wird.