git log, um nur die Commits zurückzugeben, die an den Master-Zweig gemacht wurden?

Lesezeit: 4 Minuten

Ich habe ein bisschen gesucht und gefunden:

git log myBranchName

als mögliche Lösung. Aber was passiert, wenn mein Zweig der Master-Zweig ist? wenn ich laufe:

git log master

Es scheint alles zurückzugeben, was an einen Zweig gebunden ist. Basierend auf dem, was ich gelesen habe, listet es alle Commits auf, die sich auf den Master-Zweig beziehen. Wie kann ich in diesem Wissen nur die Commit-Historie des Master-Zweigs aufrufen?

git log um nur die Commits zuruckzugeben die an den
parkydr

Ich denke das ist was du willst

git log --first-parent master

Um das Handbuch zu zitieren

Folgen Sie nur dem ersten übergeordneten Commit, wenn Sie einen Merge-Commit sehen. Diese Option kann einen besseren Überblick geben, wenn man die Entwicklung eines bestimmten Themenzweigs betrachtet, da Zusammenführungen in einen Themenzweig in der Regel nur dazu dienen, sich von Zeit zu Zeit an aktualisierte Upstreams anzupassen, und diese Option ermöglicht es Ihnen, die einzelnen Commits zu ignorieren, die in Ihre Geschichte durch eine solche Zusammenführung.

  • --first-parent master war sehr nützlich für ein Problem, mit dem ich zu tun hatte: Bestimmen Sie, welche Zusammenführungen (–merges) in den Master gingen, vs. Zusammenführungen in einem Themenzweig.

    – Matt Dressel

    20. September ’13 um 20:31

  • Danke. Ich denke, sollte ich als Lösung für dieses Problem vermarkten.

    – Konrad Szałwiński

    19. November ’14 um 18:07

  • Nur ein Hinweis, es ist nicht perfekt. Wenn die vorherige Verpflichtung zu master wird zufällig als Commit aufgeführt zweite Eltern, dies wird Ihnen die falsche geben. Dies wird jedoch normalerweise nicht passieren, wenn Sie dem Pull-Request- / Merge-Prozess von GitHub folgen.

    – PJSCopeland

    17. August ’17 um 21:36

Aufgrund des Verzweigungsmodells von Git gehören Commits nicht zu einem einzelnen oder mehreren Branches. Verzweigungen sind Zeiger auf einzelne Commit-Objekte innerhalb des gesamten Commit-Graphen. Wenn Sie also sagen, dass sich ein Commit „auf einem Branch X“ in X befindet, meinen Sie normalerweise, dass er erreichbar ist, wenn Sie bei dem Commit beginnen, auf den der Branch X zeigt.

Für git log, das Standardverhalten ist gleich git log HEAD wobei HEAD auf den Commit verweist, auf den der aktuelle Branch derzeit zeigt. Wenn Sie sich also im Master-Zweig befinden, ist es gleich git log master, zeigt alle Commits an, die erreichbar sind, wenn mit dem neuesten Commit begonnen wird.

Leider ist das, was Sie als Commit für einen bestimmten Branch bezeichnen, in Git nicht klar definiert. Wenn ich auf master einen Commit mache und dann einen neuen Branch erstelle, der auf denselben Commit zeigt (z. B. mit git branch newbranch), dann ist dieser Zweig bis auf den Namen buchstäblich mit dem Master-Zweig identisch. Also jede Immobilie „made on branch master“ würde jetzt auch bedeuten „hergestellt auf Zweigniederlassung“. Daher können Sie diese Eigenschaft nicht in Git haben.

Auch die Lösung von parkydr, die alle Commits anzeigt, die nur auf einer Seite von Merges vorgenommen wurden, ist keine ausfallsichere Lösung. Im Idealfall würde es all jene Commits verbergen, die in einem separaten Nicht-Master-Zweig gemacht wurden und die dann wieder in master zusammengeführt wurden. Als solche erhalten Sie nur Commits, die entweder direkt an die Master-Zeile gesendet werden oder Merge-Commits sind, die in andere Commits einfließen. Es gibt jedoch zwei Dinge, die verhindern, dass dies funktioniert:

  1. Fast-Forward-Merges: Wenn Sie vom Master abzweigen und einige Commits erstellen, während Sie direkt keine neuen auf Master erstellen, dann a git merge somebranch on master wird die Commits schnell vorspulen, was dazu führt, dass der master-Zweig auf denselben Commit zeigt wie irgendein Zweig. Als solches „verlieren“ Sie die Information, dass diese Commits ursprünglich in einem separaten Branch erstellt wurden. Sie können Git jedoch zwingen, immer Merge-Commits zu erstellen, indem Sie verwenden git merge --no-ff aber das hilft dir später nicht weiter.
  2. Die Merge-Reihenfolge ist nicht garantiert: Wenn Sie auf Master sind und einen Branch zusammenführen, wird der vorherige Master-Commit stets der erste Elternteil sein. Sie würden also Ihr gewünschtes Verhalten erhalten. Es ist jedoch durchaus möglich, sich in diesem Zweig zu befinden und stattdessen den Master einzufügen, was dazu führt, dass der Master-Commit der zweite Elternteil ist. Dann könnte der Master zum neuen Commit vorgespult (oder zurückgesetzt) ​​werden, was zu einer „umgekehrten“ Ansicht führt.

Die Quintessenz ist also, dass Sie eine solche Historie nicht sicher abrufen können. Sie sollten sich besser daran gewöhnen, wie das flexible Verzweigungsmodell von Git funktioniert.

.

404210cookie-checkgit log, um nur die Commits zurückzugeben, die an den Master-Zweig gemacht wurden?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy