Das Zusammenführen mit schnellem Vorlauf ist für kurzlebige Zweige sinnvoll. In einem komplexeren Verlauf kann das Zusammenführen mit nicht schnellem Vorlauf das Verständnis des Verlaufs erleichtern und das Zurücksetzen einer Gruppe von Commits erleichtern.
Warnung : Ein nicht schneller Vorlauf hat ebenfalls mögliche Nebenwirkungen. Bitte überprüfen Sie https://sandofsky.com/blog/git-workflow.html , vermeiden Sie das "no-ff" mit seinen "Checkpoint Commits", die die Halbierung oder Schuld brechen, und überlegen Sie sorgfältig, ob dies Ihr Standardansatz sein sollte master.
(Von nvie.com , Vincent Driessen , Beitrag " Ein erfolgreiches Git-Verzweigungsmodell ")
Einbeziehen eines fertigen Features in die Entwicklung
Fertige Funktionen können in den Entwicklungszweig integriert werden, um sie der kommenden Version hinzuzufügen:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
Das --no-ffFlag bewirkt, dass bei der Zusammenführung immer ein neues Festschreibungsobjekt erstellt wird, auch wenn die Zusammenführung mit einem schnellen Vorlauf durchgeführt werden könnte. Dadurch wird vermieden, dass Informationen über die historische Existenz eines Feature-Zweigs verloren gehen und alle Commits zusammengefasst werden, die das Feature hinzugefügt haben.
Jakub Narębski auch erwähnt die Configmerge.ff :
Standardmäßig erstellt Git kein zusätzliches Zusammenführungs-Commit, wenn ein Commit zusammengeführt wird, das ein Nachkomme des aktuellen Commits ist. Stattdessen wird die Spitze des aktuellen Zweigs vorgespult.
Wenn falsediese Variable auf gesetzt ist, weist sie Git an, in einem solchen Fall ein zusätzliches Merge-Commit zu erstellen (entspricht der Angabe der --no-ffOption über die Befehlszeile).
Bei der Einstellung ' only' sind nur solche Schnellvorlaufzusammenführungen zulässig (entspricht der --ff-onlyOption über die Befehlszeile).
Der schnelle Vorlauf ist die Standardeinstellung, weil:
- kurzlebige Zweige sind in Git sehr einfach zu erstellen und zu verwenden
- kurzlebige Zweige isolieren oft viele Commits, die innerhalb dieses Zweigs frei reorganisiert werden können
- Diese Commits sind tatsächlich Teil des Hauptzweigs: Sobald sie neu organisiert wurden, wird der Hauptzweig schnell weitergeleitet, um sie einzuschließen.
Wenn Sie jedoch einen iterativen Workflow für einen Themen- / Feature-Zweig erwarten (dh ich füge zusammen, dann gehe ich zurück zu diesem Feature-Zweig und füge weitere Commits hinzu), ist es nützlich, nur die Zusammenführung in den Hauptzweig aufzunehmen und nicht Alle Zwischen-Commits des Feature-Zweigs.
In diesem Fall können Sie am Ende diese Art von Konfigurationsdatei festlegen :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
Das OP fügt in den Kommentaren hinzu:
Ich sehe einen gewissen Sinn im Schnellvorlauf für [kurzlebige] Zweige, aber wenn ich ihn zur Standardaktion mache, geht Git davon aus, dass Sie ... oft [kurzlebige] Zweige haben. Angemessen?
Jefromi antwortet:
Ich denke, die Lebensdauer der Zweige ist von Benutzer zu Benutzer sehr unterschiedlich. Bei erfahrenen Benutzern besteht jedoch wahrscheinlich die Tendenz, weitaus kurzlebigere Zweige zu haben.
Für mich ist ein kurzlebiger Zweig ein Zweig, den ich erstelle, um einen bestimmten Vorgang zu vereinfachen (erneutes Basieren, wahrscheinlich oder schnelles Patchen und Testen) und dann sofort zu löschen, wenn ich fertig bin.
Das bedeutet, dass es wahrscheinlich in den Themenzweig aufgenommen werden sollte, aus dem es gespalten wurde , und der Themenzweig wird als ein Zweig zusammengeführt. Niemand muss wissen, was ich intern getan habe, um eine Reihe von Commits zu erstellen, die diese bestimmte Funktion implementieren.
Ganz allgemein füge ich hinzu:
Es hängt wirklich von Ihrem Entwicklungsworkflow ab :
- Wenn es linear ist, ist ein Zweig sinnvoll.
- Wenn Sie Features isolieren und über einen längeren Zeitraum bearbeiten und wiederholt zusammenführen müssen, sind mehrere Zweige sinnvoll.
Siehe " Wann sollten Sie verzweigen? "
Wenn Sie das Mercurial-Zweigmodell betrachten, ist es im Kern ein Zweig pro Repository (obwohl Sie anonyme Köpfe, Lesezeichen und sogar benannte Zweige erstellen können ).
Siehe "Git und Mercurial - Vergleichen und Kontrastieren" .
Mercurial verwendet standardmäßig anonyme Lightweight-Codelines, die in ihrer Terminologie als "Köpfe" bezeichnet werden.
Git verwendet leichtgewichtige benannte Zweige mit injektiver Zuordnung, um Namen von Zweigen im Remote-Repository Namen von Remote-Tracking-Zweigen zuzuordnen.
Git "zwingt" Sie, Zweige zu benennen (nun, mit Ausnahme eines einzelnen unbenannten Zweigs, der als " losgelöster HEAD " bezeichnet wird), aber ich denke, dies funktioniert besser mit verzweigungsintensiven Workflows wie dem Themenzweig-Workflow mehrere Zweige in einem einzigen Repository-Paradigma.
no-ff' mit seinen "Checkpoint Commits", die die Halbierung oder Schuld brechen.