Herausfinden, aus welchem Zweig eine Git-Übertragung stammt

Question

Gibt es eine Möglichkeit, herauszufinden, aus welchem Zweig ein Commit stammt, wenn man seine SHA-1 Hash-Wert?

Bonuspunkte gibt es, wenn Sie mir sagen können, wie man dies mit Ruby Grit erreichen kann.

Answer 1

git branch --contains <ref> ist der naheliegendste "Porzellan"-Befehl für diese Aufgabe. Wenn Sie etwas Ähnliches nur mit "Klempner"-Befehlen machen wollen:

COMMIT=$(git rev-parse <ref>) # expands hash if needed
for BRANCH in $(git for-each-ref --format "%(refname)" refs/heads); do
  if $(git rev-list $BRANCH | fgrep -q $COMMIT); then
    echo $BRANCH
  fi
done

(Querverweis von diese SO-Antwort )

Answer 2

Ich habe alle oben genannten Lösungen ausprobiert, aber keine davon hat bei mir funktioniert.

Hier ist die einzige Methode, die bei mir bisher funktioniert hat (unter der Annahme, dass HEAD an einer sinnvollen Stelle ist):

git log --branches --source | grep <sha>

#or if you also care about remotes
git log --branches --remotes --source | grep <sha>

Der Name der Verzweigung sollte am Ende der Zeile stehen.

Von der Dokumentation

--Quelle

Gibt den in der Befehlszeile angegebenen Referenznamen aus, mit dem jede Übergabe erreicht wurde.

Dies kann sich also ändern, je nachdem, wo HEAD ist, aber für mich ist das HEAD bei der letzten Übergabe in meinem Master-Zweig führte zu den erwarteten Ergebnissen.

Sichtprüfung mit gitk --all kann ebenfalls hilfreich sein. Es hat ein Feld "Zweige" für jeden Commit, aber es zeigt alle Zweige an, die diesen Commit "erreichen" können, nicht notwendigerweise den Zweig, auf dem dieser Commit "liegt". Siehe hier

---

Nebenbei bemerkt:

Es ist auch erwähnenswert, dass diese Frage ein wenig irreführend ist. Im Gegensatz zu anderen SVCs sind Zweige in Git nur temporäre Verweise auf Orte in Ihrer Commit-Historie/Grafik. Sie "besitzen" keine Commits und sind auch nicht "aus" Commits zusammengesetzt. Sie sind im Grunde nur Tags, die auf jeden Commit aktualisiert werden, den Sie pushen, während Sie das Tag ausgecheckt haben. Ein Branch ist also keine Reihe von Commits, sondern eher ein Zeiger auf das Ende/Spitze einer Reihe von Commits. Demzufolge "gehören" oder "kommen" Commits nicht zu einem Branch, sie sind nur Knoten in Ihrem Graphen.

Was machen wir hier eigentlich? Wir nutzen die Idee der Erreichbarkeit. Wenn wir bei dem Commit beginnen, auf den jeder Zweig zeigt (das "Ende" des "Zweigs") und rückwärts durch die Geschichte gehen, welche Commits können wir finden/erreichen? Wir sagen, dass Commits "auf" einem Zweig sind, wenn die einzige Möglichkeit, sie zu finden, darin besteht, unsere Suche auf diesem bestimmten Zweig zu beginnen.

Beachten Sie, dass dies keine stabile Sache ist. Wenn wir unseren Zweig zusammenführen, umbenennen oder rebasen, wird sich plötzlich ändern, welche Commits für unseren Zweig erreichbar sind (und somit 'auf'). Aus diesem Grund sind Commits, die einem bestimmten Zweig gehören, kein offizielles oder immer sinnvolles Konzept in Git. (und warum diese Frage keine klare/definitive Antwort hat)

Answer 3

Ich habe mit demselben Problem zu kämpfen ( Jenkins Multibranch-Pipeline) - die nur Commit-Informationen hat und versucht, den Namen des Zweigs zu finden, aus dem diese Commit ursprünglich stammt. Es muss für entfernte Zweige funktionieren, lokale Kopien sind nicht verfügbar.

Das ist das, womit ich arbeite:

git rev-parse HEAD | xargs git name-rev

Optional können Sie die Ausgabe ausblenden:

git rev-parse HEAD | xargs git name-rev | cut -d' ' -f2 | sed 's/remotes\/origin\///g'

Answer 4

Eine Option für den armen Mann ist die Verwendung von das Werkzeug tig 1 auf HEAD , suchen Sie nach dem Commit, und folgen Sie dann visuell der Linie von diesem Commit zurück nach oben, bis ein Merge-Commit zu sehen ist. Die Standard-Zusammenführungsnachricht sollte angeben, welcher Zweig wohin zusammengeführt wird :)

1 Tig ist eine ncurses-basierte Textmodus-Schnittstelle für Git. Es funktioniert hauptsächlich als Git-Repository-Browser, aber es kann auch bei der Bereitstellung von Änderungen für die Übergabe auf Chunk-Ebene und als Pager für die Ausgabe von verschiedenen Git-Befehlen.

Answer 5

Als Experiment habe ich einen Post-Commit-Hook erstellt, der Informationen über den aktuell ausgecheckten Zweig in den Commit-Metadaten speichert. Ich habe auch gitk leicht modifiziert, um diese Informationen anzuzeigen.

Sie können es hier nachlesen: https://github.com/pajp/branch-info-commits