"Dieser Zweig ist 1 Commit voraus, 1 Commit hinter dem Master" in Github, während "ein erfolgreiches Git-Verzweigungsmodell" verwendet wird
Ich arbeite in einem sauberen Repo mit nur einer einzigen Datei. Ich bin der einzige Entwickler.
Ich möchte den Entwicklungs-Release-Master-Workflow in einem erfolgreichen Git-Branching-Modell durchführen > Ich tat es so:
Hinweis: Bitte beachten Sie, dass ich den schnellen Vorlauf standardmäßig deaktiviert habe. Beachten Sie daher alle merge -Befehle als merge --no-ff .
Mein Ursprung ist Github.
Im Zweig master :
%Vor%In Entwicklung Zweig. Ich mache eine Änderung an der Datei, dann:
%Vor%Ich bin bereit, dies als die Version 0.0 zu veröffentlichen
%Vor%In der release-0.0 Verzweigung. Ich füge der Datei eine Versionsnummer hinzu.
%Vor%Ich bin bereit, diese Version in Master zusammenzuführen.
%Vor%... und entwickeln.
%Vor%Dann schiebe ich sowohl master als auch entwickelt nach Github
%Vor%Wenn ich den Zweig develop in Github überprüfe, 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? Sowohl master als auch develop sollten zu diesem Zeitpunkt gleich sein, da beide mit release-0.0 zusammengeführt wurden.
3 Antworten
Nein, es wird nicht gleich sein, da Sie den Schnellvorlauf 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.
Wie für die Nachricht, die nicht im Master vorhanden ist, liegt das 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, Fast-Forward zu aktivieren und explizit Zusammenführungs-Commits in Release und Master zu erstellen und dann das schnelle Weiterleiten zu entwickeln. Die andere Möglichkeit besteht darin, nach jeder Zusammenführung neu zu entwickeln. Wie Sie vorgehen möchten, hängt von Ihrem Workflow und Ihrem Code ab.
Auch die Nachricht, die da ist, sollte Sie nicht beunruhigen, solange der Code in den Zweigen genau so ist, wie Sie wollen.
Nur zu den anderen Antworten hinzufügen:
Der ursprüngliche git-flow wurde seit 2012 nicht mehr weiterentwickelt und wurde durch git-flow AVH-Ausgabe an vielen Stellen (einschließlich der Ubuntu-Repositories und Git für Windows ).
Einer der von der AVH-Edition eingeführten Unterschiede ist, dass die endgültige Zusammenführung die von master * in entwickeln und nicht die von release ist in entwickeln .
Dies macht master zu einem direkten Elternteil von entwickeln und sollte einen Teil der Nachricht, die Sie sehen, eliminieren; 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 ist es das neue Tag (im Master), das in develop zusammengeführt wird.
Weil du --no-ff benutzt, wird jedes einzelne ein anderes Commit sein. Wenn Sie relese-0.0 in develop und in master zusammenführen, sind die Zusammenführungs-Commits unterschiedlich. So sieht es aus:
Wie Sie die Entwicklung Zweig sehen können, hat einen commit (Merge 0.0 in der Entwicklung zu), die nicht in (nicht erreichbar von) der Master und der Master-Zweig hat ein commit (Releasing v0.0), die nicht in der Entwicklung Ast. Und das ist, was gihub sagt mit dieser Botschaft, und es ist völlig in Ordnung (die Inhalte sind die gleichen, aber die Commits anders).
Wenn Sie möchten, dass git verwenden fließen Sie einen Blick sollte unter Ссылка , die Ihnen helfen, eine Menge.
Tags und Links git github git-branch branching-and-merging