Gitflow: Feature-Zweig mit Single-Commit mit Fast-Forward zusammengeführt

Erstellt am 18. Jan. 2013  ·  24Kommentare  ·  Quelle: nvie/gitflow

Hallo,

Das git-flow-feature hat eine explizite Prüfung um Zeile 310, wo es explizit schnell vorwärts zusammengeführt wird, wenn der Feature-Zweig einen Commit enthält.

Ich verstehe den Grund dafür nicht wirklich, denn obwohl es sich um einen Commit handelt, ist es immer noch sehr nützlich zu wissen, dass eine bestimmte Funktion implementiert wurde (für die ein echter Merge-Commit als Metadaten fungiert). Es scheint auch sehr unvereinbar mit dem vorgeschlagenen Entwicklungsmodell zu sein.

Gerne einen Patch anbieten, um den --no-ff-Zweig zum Standard zu machen.

Danke, Alex J. Burke.

Hilfreichster Kommentar

Bei jeder neuen Veröffentlichung ist dies das erste, was ich checke :D und es ist nie da :/

Alle 24 Kommentare

Habe das heute auch gerade selbst gefunden. Hier wurde bereits ein Problem angesprochen und geschlossen: https://github.com/nvie/gitflow/issues/100, aber ich stimme zu, dass es nicht mit dem Entwicklungsmodell übereinstimmt. Hoffentlich können wir hier etwas ändern, wenn sich genug Leute aufregen. (Ich bin nicht versiert genug, um diese Änderung privat vorzunehmen.)

Habe angefangen, beide Probleme zu beobachten. Ich bin mir noch nicht sicher, welchen Weg ich bevorzuge, aber eine Option ist fast immer besser als gar keine, oder?

In meinem Fork git-flow (AVH Edition) wird ein Flag für diese Funktion eingeführt.
Mein Fork ist zu stark abgewichen, um dies zu einem einfachen Pull-Request für nvies Gitflow zu machen.

Sehen Sie sich das Changelog an, um weitere Informationen zu Bugfixes und neuen Funktionen zu erhalten, die in meinem Fork implementiert sind.

Einverstanden. Zumindest würde ich gerne die Gründe dafür sehen.

Einverstanden - das Verhalten ist nicht offensichtlich, insbesondere für neue Gitflow-Benutzer.

Ein Grund für dieses Flag ist ein Workflow, der einen Überprüfungsprozess beinhaltet. Ich möchte die Zusammenführungsanfrage mit einer Ticketnummer versehen können, auch wenn das Ticket nur einen einzigen Commit umfasst. Ja, zusätzliche Merge-Commits können im Allgemeinen Rauschen verursachen, aber in einem Workflow wie diesem ist es wichtig, zu einem Ticket zurückzuverfolgen, ohne unbedingt die Commit-Nachricht selbst bearbeiten zu müssen (da die Ticketnummer möglicherweise nicht von Anfang an vorhanden war).

Ich war sehr schlecht im Kommentieren, aber abgesehen von meiner ursprünglichen Beobachtung denke ich, dass viele andere ihre Anwendungsfälle beigetragen und den Nutzen weiter begründet haben.

So wie es aussieht, bin ich jedoch verwirrt, wo ich Patches und Verbesserungen beitragen soll - wobei das ursprüngliche Git-Flow-Projekt scheinbar nicht gepflegt wird und keiner der Forks als Nachfolger gesegnet ist.

Fürs Protokoll glaube ich, dass die 'AVH'-Gabel so etwas wie diese Änderung enthielt, die hinter einer Flagge saß (ich glaube standardmäßig deaktiviert), aber sie hatte auch eine späte Anzahl verschiedener anderer Änderungen, die ich zuletzt überprüft habe.

  • spät -> groß

+1, um zumindest eine Option hinzuzufügen, damit der Benutzer --no-ff erzwingen kann, auch wenn der Zweig nur einen Commit enthält :+1:

Ich hatte heute Mühe zu verstehen, warum ich meinen Merge-Commit nicht hatte und warum es plötzlich einen schnellen Vorlauf durchführte, mich fragen musste, was ich falsch gemacht habe usw. ... bis ich entdeckte, dass es gitflow selbst war, das dies tat, ohne mir davon zu erzählen .

Wenn ich einen Quick Fix starte, der nur einen Commit benötigt, und ich explizit keinen Merge-Commit und kein Fast-Forward möchte, dann commite ich einfach direkt in meinem develop Zweig. Ich habe das immer gemacht. Wenn ich einen Feature-Branch erstelle, auch nur für einen Commit, wird dieser Branch beibehalten und verschwindet nicht (wegen des schnellen Vorlaufs) beim Merge. Wenn ich diesen Branch nicht wollte, hätte ich mich direkt auf die Entwicklung festgelegt und den Feature-Branch nicht von Anfang an erstellt.

Bitte fügen Sie zumindest ein Flag oder einen Konfigurationseintrag hinzu, damit der Benutzer wählen kann, welches Verhalten er wünscht, anstatt den schnellen Vorlauf unter bestimmten (verständlichen, aber willkürlichen) Bedingungen unerwartet zu deaktivieren :wink:

Mein Fork git-flow (AVH Edition) hat die Option Flags als Standard zu setzen, auf diese Weise können Sie immer ein --no-ff ausführen, ohne es einzugeben. Weitere Informationen finden Sie im Wiki .

Mein Fork ist zu stark abgewichen, um dies zu einem einfachen Pull-Request für nvies Gitflow zu machen.

Sehen Sie sich das Changelog an, um weitere Informationen zu Bugfixes und neuen Funktionen zu erhalten, die in meinem Fork implementiert sind.

@petervanderdoes Danke.

Eigentlich fair zu sein Ich bin nicht gitflow Kommandozeile aber mit SourceTree GUI , der @nvie ‚s zu verwenden scheint gitflow Kommandozeile intern. Ich bin mir nicht sicher, ob SourceTree eine alternative git-flow Version/ausführbare Datei verwenden kann und wie?

In der abschließenden Ausgabe #100 irrt sich Zweigbaum unnötig verkompliziert“, während der Kommentar der Zusammenführung tatsächlich der einzige Datensatz ist, der für zukünftige Generationen übrig geblieben ist Tatsache, dass (a) ein Feature-Zweig erstellt wurde und (b) der Name des Feature-Zweigs tatsächlich war. Ohne ein explizites Merge ohne Fast-Forward verliert der Projektverlauf die Information, dass der Commit ein Branch und überhaupt ein Feature war!

Es wäre schön, wenn das angesprochen würde

Ich wäre versucht, die explizite Option --ff aus dem Fall eines einzelnen Commits zu entfernen. Dann kann die eingebaute git-Merge-Konfiguration merge.ff=false verwendet werden, um --no-ff für alle Zusammenführungen (einschließlich derer nach Flow-Finish) festzulegen, wobei die standardmäßige git-Konfiguration das aktuelle Verhalten repliziert.

+1

Zumindest wäre es schön, wenn dieses "Feature" dokumentiert würde.

Irgendwelche Fortschritte in dieser Hinsicht, ich weiß, dass ich eine alte wiederaufbereite, aber wir sehen keine Möglichkeit, Sourcetree zu verwenden, um eine Funktion zu schließen, ohne die Zusammenführung schnell weiterzuleiten. Es gibt eine Einstellung in den Einstellungen, aber sie scheint sie nicht zu respektieren

+1

+1

Siehe "Ist dieses Repository tot? #6340"

Es stellte sich heraus, dass Sie git einfach ohne dies verwenden können! 😝

Nicht dokumentiert und geben einer Verwendung keine Option.
Diese Art von Entscheidungen sollte auf der Seite des Benutzers getroffen werden. Warum nicht ein kleines Kontrollkästchen im Dialogfeld "Version beenden" setzen und wenn Sie wirklich ein großer Fan dieser Funktion sind, lassen Sie es standardmäßig ankreuzen, aber da ich es nicht bin, kann ich es deaktivieren, oder?

Bei jeder neuen Veröffentlichung ist dies das erste, was ich checke :D und es ist nie da :/

Habe gerade festgestellt, dass es in den Einstellungen auch eine Checkbox dafür gibt. Sie müssen es also nicht bei jeder Zusammenführung von Zweigen überprüfen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen