Gitflow: Feature-Ende führt keine --no-ff-Zusammenführung durch

Hallo Scott,

git-flow verwendet beim Zusammenführen standardmäßig die Option --no-ff , um festzuhalten, dass die Commits historisch zusammengehören. Wenn der Feature-Zweig jedoch nur einen einzigen Commit enthält, fügt der zusätzliche Merge-Commit nichts hinzu und verkompliziert nur den Zweigbaum unnötig. Für Single-Commit-Zweigs werden also Fast-Forward-Zusammenführungen durchgeführt, als ob der Commit direkt für develop .

Beifall,
Vincent

Hallo Vincent,

Ich kann den Gedanken hinter diesem Design definitiv verstehen, aber ich denke, dass die Entscheidung, ob der Merge-Commit erstellt werden soll, davon abhängen sollte, ob der Benutzer einen Feature-Branch startet. Manchmal nehme ich vielleicht schnelle Änderungen am Entwicklungszweig vor, aber ich entscheide mich dafür, einen Feature-Zweig _spezifisch_ zu erstellen, weil ich den Merge-Commit sehen möchte. Möglicherweise mache ich nur einen einzigen Commit für einen Feature-Branch, aber es ist möglicherweise nicht das, was ich als Benutzer für unbedeutend genug halte, um ein explizites Merge-Commit zu ignorieren.

Letztendlich denke ich, dass die Wahl beim Benutzer liegen sollte, und ich denke, dass der Benutzer eine andere Wahl trifft, indem er einen Feature-Branch verwendet, als wenn er sich schnell auf den Entwicklungs-Branch einlässt.

Alle Hinweise, wo ich in der Codebasis gehen könnte, um diese Änderung in einer privaten Form vorzunehmen, wäre sehr dankbar!

Vielen Dank für ein tolles Werkzeug!
-Scott

Hier passiert die Magie: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

Ich werde keine Option hinzufügen, um die Single-Commit-Funktionszweige explizit mit --no-ff zusammenzuführen, da ich immer noch nicht glaube, dass dies etwas hinzufügt (außer der zusätzlichen Komplexität eines anderen Befehlszeilen-Flags), aber Fühlen Sie sich frei, es zu einer privaten Änderung zu machen, wenn Sie darauf bestehen.

Beifall,
Vincent

Danke, Vincent! Ich schätze den Hinweis!

Am besten,
Scott

Wenn ich meine 5 Cent dazuzählen darf,

Ich würde sehr gerne eine Option für einen Merge-Commit haben, auch wenn eine Commit-Funktion abgeschlossen ist.

So wie ich git flow verwende, enthalten meine Funktionen in ihrem Namen die Ticketnummer, an der ich arbeite. Wenn ich ein Feature fertig habe, würde ich mir sehr wünschen, dass der Merge-Commit den Feature-Namen (einschließlich der Ticketnummer) angibt.

Dies ist nützlich, um jeden Commit auf das eigentliche Ticket zurückzuverfolgen, ohne die Ticketnummer in jede Commit-Nachricht schreiben zu müssen.

@DonGiulio Ich weiß nicht, ob Sie es bereits

Danke, das wusste ich nicht, werde ich mir anschauen.

Ich entscheide mich auch dafür, einfach eine Option hinzuzufügen, um Single-Commit-No-Off-Verhalten zu haben. Es wäre schön, wenn Sie dies noch einmal überdenken könnten.

(Ich bin mir nicht sicher, was sonst noch in der AVH-Ausgabe steht).

@nvie Darf ich warum?! "_Ich glaube immer noch nicht, dass es etwas hinzufügt_"
Ich dachte ehrlich , wenn Haufen Leute glauben , es tut etwas hinzufügen und einige denken , es ist nicht , dass wir eine Option hinzufügen , dass es irgendwo oder zumindest Dokument , um es so Leute nicht brauchen es durch Versuch und Irrtum zu finden. Das kann keine so große Entscheidung sein!

Wenn der Benutzer sich die Mühe machte, ein Feature zu erstellen und sich dafür entschied, einen einzelnen Commit darin durchzuführen, bedeutet dies, dass er/sie es so brauchte (zum Beispiel aus Gründen der visuellen Historie) und nicht direkt auf die Entwicklung drängte . Ich würde umgekehrt argumentieren und den Weg des Benutzers zu ignorieren, macht keinen Sinn.

Möchten Sie näher darauf eingehen? Wir sollten uns einig sein, dass nicht jeder aufgrund solcher geringfügiger Änderungen ein so solides Werk abzweigen möchte.

@Mehradzie Es gab seit 5 Jahren keinen Commit für dieses Repo. Die AVH-Edition ist seit einiger Zeit die erste Wahl und ist recht stabil. Ich würde hier nicht den Atem anhalten, um eine Antwort zu erhalten, geschweige denn eine Codeänderung.

@jawshooah Um ehrlich zu sein, habe ich nicht einmal den Repo-Namen überprüft, als ich hier gelandet bin, da ich das gleiche Problem in SourceTree verfolgte.
Ist gitflow das, was SourceTree für seine Flows verwendet? Ich bin gerade etwas verwirrt :D
Und wenn ja, kann ich es hacken und ändern, wie Sie vorgeschlagen haben, stattdessen die Arbeit anderer Repos zu verwenden!

@Mehradzie AFAIK SourceTree bettet eine leicht modifizierte Version der ursprünglichen nvie-Version ein. Es gibt noch offene Anfragen für ein Update auf die AVH-Version (siehe hier und hier ).