English ▾ Themen ▾ Neueste Version ▾ git-merge-base zuletzt aktualisiert in 2.43.0

NAME

git-merge-base - Finde möglichst gute gemeinsame Vorfahren für einen Merge

SYNOPSIS

git merge-base [-a | --all] <commit> <commit>…​
git merge-base [-a | --all] --octopus <commit>…​
git merge-base --is-ancestor <commit> <commit>
git merge-base --independent <commit>…​
git merge-base --fork-point <ref> [<commit>]

BESCHREIBUNG

git merge-base findet die besten gemeinsamen Vorfahren zwischen zwei Commits, die für einen Drei-Wege-Merge verwendet werden. Ein gemeinsamer Vorfahre ist *besser* als ein anderer gemeinsamer Vorfahre, wenn letzterer ein Vorfahre des ersteren ist. Ein gemeinsamer Vorfahre, der keine besseren gemeinsamen Vorfahren hat, ist ein *bester gemeinsamer Vorfahre*, d. h. eine *Merge-Basis*. Beachten Sie, dass es mehr als eine Merge-Basis für ein Paar von Commits geben kann.

OPERATION MODES

Im häufigsten Sonderfall bedeutet die Angabe von nur zwei Commits auf der Kommandozeile die Berechnung der Merge-Basis zwischen den gegebenen zwei Commits.

Allgemeiner gesagt, von den beiden Commits, von denen die Merge-Basis berechnet werden soll, wird einer durch das erste Commit-Argument auf der Kommandozeile spezifiziert; der andere Commit ist ein (möglicherweise hypothetischer) Commit, der ein Merge über alle verbleibenden Commits auf der Kommandozeile ist.

Als Konsequenz ist die *Merge-Basis* nicht notwendigerweise in jedem der Commit-Argumente enthalten, wenn mehr als zwei Commits angegeben werden. Dies unterscheidet sich von git-show-branch[1], wenn es mit der Option --merge-base verwendet wird.

--octopus

Berechnet die besten gemeinsamen Vorfahren aller angegebenen Commits zur Vorbereitung eines n-Wege-Merges. Dies ahmt das Verhalten von git show-branch --merge-base nach.

--independent

Anstatt Merge-Basen auszugeben, wird eine minimale Teilmenge der angegebenen Commits mit denselben Vorfahren ausgegeben. Mit anderen Worten, unter den gegebenen Commits werden diejenigen aufgelistet, die von keinem anderen erreicht werden können. Dies ahmt das Verhalten von git show-branch --independent nach.

--is-ancestor

Prüft, ob der erste <Commit> ein Vorfahre des zweiten <Commit> ist, und beendet das Programm mit dem Status 0, wenn dies zutrifft, oder mit dem Status 1, wenn nicht. Fehler werden durch einen Rückgabewert ungleich Null signalisiert, der nicht 1 ist.

--fork-point

Findet den Punkt, an dem ein Branch (oder jede Historie, die zu <Commit> führt) von einem anderen Branch (oder einer Referenz) <Ref> abgezweigt ist. Dies sucht nicht nur nach dem gemeinsamen Vorfahren der beiden Commits, sondern berücksichtigt auch die Reflogs von <Ref>, um zu sehen, ob die Historie, die zu <Commit> führt, von einer früheren Inkarnation des Branches <Ref> abgezweigt ist (siehe Diskussion dieses Modus unten).

OPTIONEN

-a
--all

Gibt alle Merge-Basen für die Commits aus, anstatt nur eine.

DISKUSSION

Gegeben zwei Commits A und B, gibt git merge-base A B einen Commit aus, der von beiden A und B über die Eltern-Beziehung erreichbar ist.

Zum Beispiel, mit dieser Topologie

	 o---o---o---B
	/
---o---1---o---o---o---A

ist die Merge-Basis zwischen A und B 1.

Gegeben drei Commits A, B und C, berechnet git merge-base A B C die Merge-Basis zwischen A und einem hypothetischen Commit M, der ein Merge zwischen B und C ist. Zum Beispiel, mit dieser Topologie

       o---o---o---o---C
      /
     /   o---o---o---B
    /   /
---2---1---o---o---o---A

ist das Ergebnis von git merge-base A B C 1. Dies liegt daran, dass die äquivalente Topologie mit einem Merge-Commit M zwischen B und C lautet

       o---o---o---o---o
      /                 \
     /   o---o---o---o---M
    /   /
---2---1---o---o---o---A

und das Ergebnis von git merge-base A M ist 1. Commit 2 ist ebenfalls ein gemeinsamer Vorfahre zwischen A und M, aber 1 ist ein besserer gemeinsamer Vorfahre, da 2 ein Vorfahre von 1 ist. Daher ist 2 keine Merge-Basis.

Das Ergebnis von git merge-base --octopus A B C ist 2, da 2 der beste gemeinsame Vorfahre aller Commits ist.

Wenn die Historie sich kreuzende Merges beinhaltet, kann es mehr als einen *besten* gemeinsamen Vorfahren für zwei Commits geben. Zum Beispiel, mit dieser Topologie

---1---o---A
    \ /
     X
    / \
---2---o---o---B

sind sowohl 1 als auch 2 Merge-Basen von A und B. Keiner von beiden ist besser als der andere (beide sind *beste* Merge-Basen). Wenn die Option --all nicht gegeben ist, ist nicht spezifiziert, welcher beste ausgegeben wird.

Ein übliches Idiom zur Prüfung der "Fast-Forward-Fähigkeit" zwischen zwei Commits A und B ist (oder war zumindest früher), die Merge-Basis zwischen A und B zu berechnen und zu prüfen, ob sie gleich A ist. In diesem Fall ist A ein Vorfahre von B. Sie werden dieses Idiom oft in älteren Skripten sehen.

A=$(git rev-parse --verify A)
if test "$A" = "$(git merge-base A B)"
then
	... A is an ancestor of B ...
fi

Im modernen Git können Sie dies direkter ausdrücken

if git merge-base --is-ancestor A B
then
	... A is an ancestor of B ...
fi

stattdessen.

Diskussion über den Fork-Point-Modus

Nachdem Sie an dem mit git switch -c topic origin/master erstellten topic-Branch gearbeitet haben, kann die Historie des Remote-Tracking-Branches origin/master zurückgespult und neu aufgebaut worden sein, was zu einer Historie dieser Form führt

		 o---B2
		/
---o---o---B1--o---o---o---B (origin/master)
	\
	 B0
	  \
	   D0---D1---D (topic)

wobei origin/master früher auf die Commits B0, B1, B2 zeigte und jetzt auf B zeigt, und Ihr topic-Branch wurde darauf aufgebaut, als origin/master auf B0 war, und Sie haben drei Commits, D0, D1 und D, darauf aufgebaut. Stellen Sie sich vor, Sie möchten nun die auf dem Topic geleistete Arbeit auf den aktualisierten origin/master neu basieren.

In diesem Fall würde git merge-base origin/master topic den Elternteil von B0 im obigen Bild zurückgeben, aber B0^..D ist **nicht** der Bereich von Commits, den Sie auf B wiedergeben möchten (er enthält B0, was nicht das ist, was Sie geschrieben haben; es ist ein Commit, den die andere Seite verworfen hat, als sie ihre Spitze von B0 auf B1 verschoben hat).

git merge-base --fork-point origin/master topic wurde entwickelt, um in solchen Fällen zu helfen. Er berücksichtigt nicht nur B, sondern auch B0, B1 und B2 (d. h. alte Spitzen der Remote-Tracking-Branches, die Ihr Repository-Reflog kennt), um zu sehen, auf welchem Commit Ihr Topic-Branch aufgebaut wurde, und findet B0, wodurch Sie nur die Commits auf Ihrem Topic wiedergeben können, ohne die Commits auszuschließen, die die andere Seite später verworfen hat.

Daher

$ fork_point=$(git merge-base --fork-point origin/master topic)

findet B0, und

$ git rebase --onto origin/master $fork_point topic

wird D0, D1 und D auf B wiedergegeben, um eine neue Historie dieser Form zu erstellen

		 o---B2
		/
---o---o---B1--o---o---o---B (origin/master)
	\                   \
	 B0                  D0'--D1'--D' (topic - updated)
	  \
	   D0---D1---D (topic - old)

Eine Einschränkung ist, dass ältere Reflog-Einträge in Ihrem Repository von git gc abgelaufen sein können. Wenn B0 nicht mehr im Reflog des Remote-Tracking-Branches origin/master erscheint, kann der `--fork-point`-Modus ihn offensichtlich nicht finden und schlägt fehl, um ein zufälliges und nutzloses Ergebnis zu vermeiden (wie z. B. den Elternteil von B0, wie es derselbe Befehl ohne die Option `--fork-point` liefert).

Außerdem muss der Remote-Tracking-Branch, mit dem Sie den `--fork-point`-Modus verwenden, derjenige sein, von dessen Spitze Ihr Topic abgezweigt ist. Wenn Sie von einem älteren Commit als der Spitze abgezweigt sind, findet dieser Modus den Fork-Punkt nicht (stellen Sie sich in der obigen Beispielhistorie vor, B0 existierte nicht, origin/master begann bei B1, ging zu B2 und dann zu B, und Sie haben Ihr Topic bei origin/master^ abgezweigt, als origin/master B1 war; die Form der Historie wäre dieselbe wie oben, ohne B0, und der Elternteil von B1 ist das, was git merge-base origin/master topic korrekt findet, aber der `--fork-point`-Modus wird es nicht, da es keiner der Commits ist, die sich früher an der Spitze von origin/master befanden).

Siehe auch

git-rev-list[1], git-show-branch[1], git-merge[1]

GIT

Teil der git[1] Suite