Czy istnieje sposób, aby dowiedzieć się, z jakiej gałęzi pochodzi zatwierdzenie, biorąc pod uwagę jego wartość skrótu SHA-1 ?

Punkty bonusowe, jeśli możesz mi powiedzieć, jak to osiągnąć za pomocą Ruby Grit.

Chociaż Dav ma rację, że informacje nie są bezpośrednio przechowywane, to nie znaczy, że nigdy nie dowiesz się. Oto kilka rzeczy, które możesz zrobić.

Znajdź gałęzie, na których zatwierdzenie jest włączone

git branch -a --contains <commit>

To powie ci wszystkie gałęzie, które mają dane zatwierdzenie w swojej historii. Oczywiście jest to mniej przydatne, jeśli zatwierdzenie zostało już połączone.

Szukaj w reflogs

Jeśli pracujesz w repozytorium, w którym dokonano zatwierdzenia, możesz przeszukać dzienniki referencyjne w poszukiwaniu tego zatwierdzenia. Reflogi starsze niż 90 dni są przycinane przez git-gc, więc jeśli zatwierdzenie jest za stare, nie znajdziesz go. To powiedziawszy, możesz to zrobić:

git reflog show --all | grep a871742

znaleźć zatwierdzić a871742. Zauważ, że MUSISZ użyć skrótu 7 pierwszych cyfr zatwierdzenia. Wynik powinien być mniej więcej taki:

a871742 refs/heads/completion@{0}: commit (amend): mpc-completion: total rewrite

wskazując, że zatwierdzenie zostało dokonane w gałęzi „zakończenie”. Domyślne wyjście pokazuje skrócone skróty zatwierdzania, więc nie szukaj pełnego skrótu, bo nic nie znajdziesz.

git reflog showjest właściwie tylko aliasem git log -g --abbrev-commit --pretty=oneline, więc jeśli chcesz majstrować przy formacie wyjściowym, aby udostępnić różne rzeczy do grep, to jest twój punkt wyjścia!

Jeśli nie pracujesz w repozytorium, w którym dokonano zatwierdzenia, najlepsze, co możesz zrobić w tym przypadku, to przejrzeć dzienniki logowania i dowiedzieć się, kiedy zatwierdzenie zostało po raz pierwszy wprowadzone do repozytorium; przy odrobinie szczęścia trafiłeś do gałęzi, do której był zaangażowany. Jest to nieco bardziej skomplikowane, ponieważ nie można jednocześnie przejść do drzewa zatwierdzeń i dzienników zmian. Chcesz przeanalizować dane wyjściowe dziennika ponownego sprawdzenia, sprawdzając każdy skrót, aby sprawdzić, czy zawiera on pożądany zatwierdzenie, czy nie.

Znajdź kolejne zatwierdzenie scalania

Jest to zależne od przepływu pracy, ale przy dobrych przepływach pracy zatwierdzenia są dokonywane w gałęziach programistycznych, które są następnie scalane. Możesz to zrobić:

git log --merges <commit>..

aby zobaczyć zatwierdzenia scalania, które mają dane zatwierdzenie jako przodka. (Jeśli zatwierdzenie zostało scalone tylko raz, pierwszym powinno być scalenie, którego szukasz; w przeciwnym razie będziesz musiał zbadać kilka). Komunikat zatwierdzenia scalenia powinien zawierać nazwę gałęzi, która została scalona.

Jeśli chcesz na tym polegać, możesz użyć --no-ffopcji, git mergeaby wymusić utworzenie zatwierdzenia scalania nawet w przypadku szybkiego przewijania. (Nie bądź jednak zbyt chętny. To może stać się zaciemniające, jeśli będzie nadużywane) . Odpowiedź VonC na powiązane pytanie pomaga w opracowaniu tego tematu.

To proste polecenie działa jak urok:

git name-rev <SHA>

Na przykład (gdzie gałąź testowa to nazwa gałęzi):

git name-rev 651ad3a
251ad3a remotes/origin/test-branch

Nawet to działa w przypadku złożonych scenariuszy, takich jak:

origin/branchA/
              /branchB
                      /commit<SHA1>
                                   /commit<SHA2>

Tu git name-rev commit<SHA2>zwraca branchB .

Aktualizacja z grudnia 2013 r .:

sschuberth komentarze

git-what-branch(Skrypt Perla, patrz poniżej) nie wydaje się już utrzymywany. git-when-mergedto alternatywa napisana w Pythonie, która działa dla mnie bardzo dobrze.

Opiera się na „ Znajdź zatwierdzenie scalania, które zawiera określone zatwierdzenie ”.

git when-merged [OPTIONS] COMMIT [BRANCH...]

Sprawdź, kiedy zatwierdzenie zostało scalone w co najmniej jedną gałąź.
Znajdź zatwierdzenie scalania, które wprowadziło COMMITdo określonych ODDZIAŁÓW.

W szczególności poszukaj najstarszego zatwierdzenia w historii pierwszego rodzica, BRANCHktóry zawiera COMMITjako przodek.

Oryginalna odpowiedź wrzesień 2010:

Sebastien Douche dopiero co wyszedł (16 minut przed odpowiedzią SO):

git-what-branch : Dowiedz się, na jakiej gałęzi znajduje się zatwierdzenie lub jak dotarł do nazwanej gałęzi

To jest skrypt Perla od Setha Robertsona, który wydaje się bardzo interesujący:

STRESZCZENIE

git-what-branch [--allref] [--all] [--topo-order | --date-order ]
[--quiet] [--reference-branch=branchname] [--reference=reference]
<commit-hash/tag>...

PRZEGLĄD

Podaj nam (domyślnie) najwcześniejszą przyczynową ścieżkę zatwierdzeń i scaleń, aby żądane zatwierdzenie dotarło do nazwanego oddziału. Jeśli zatwierdzenia dokonano bezpośrednio w nazwanej gałęzi, jest to oczywiście najwcześniejsza ścieżka.

Przez najwcześniejszą ścieżkę przyczynową rozumiemy ścieżkę, która najwcześniej połączyła się w nazwanej gałęzi, przez czas zatwierdzenia (chyba że --topo-orderokreślono inaczej ).

WYDAJNOŚĆ

Jeśli wiele gałęzi (np. Setki) zawiera zatwierdzenie, system może zająć dużo czasu (dla konkretnego zatwierdzenia w drzewie Linuksa zajęło 8 sekund zbadanie gałęzi, ale było ponad 200 kandydujących gałęzi), aby wyśledzić ścieżkę do każdego zatwierdzenia.
Wybór konkretnego --reference-branch --reference tagdo zbadania będzie setki razy szybszy (jeśli masz setki kandydujących gałęzi).

PRZYKŁADY

 # git-what-branch --all 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto master using the following minimal temporal path:
   v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May  5 08:59:37 2005)
   v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Tue May  3 18:27:24 2005)
   v2.6.12-rc3-461-g84e48b6 is on master
   v2.6.12-rc3-461-g84e48b6 is on v2.6.12-n
   [...]

Ten program nie bierze pod uwagę skutków wybrania interesującego zatwierdzenia, tylko operacje scalania.

Na przykład, aby znaleźć to c0118fazatwierdzenie pochodzi z redesign_interactions:

* ccfd449 (HEAD -> develop) Require to return undef if no digits found
*   93dd5ff Merge pull request #4 from KES777/clean_api
|\
| * 39d82d1 Fix tc0118faests for debugging debugger internals
| * ed67179 Move &push_frame out of core
| * 2fd84b5 Do not lose info about call point
| * 3ab09a2 Improve debugger output: Show info about emitted events
| *   a435005 Merge branch 'redesign_interactions' into clean_api
| |\
| | * a06cc29 Code comments
| | * d5d6266 Remove copy/paste code
| | * c0118fa Allow command to choose how continue interaction
| | * 19cb534 Emit &interact event

Powinieneś uruchomić:

git log c0118fa..HEAD --ancestry-path --merges

I przewiń w dół, aby znaleźć ostatnie zatwierdzenie scalania . Który jest:

commit a435005445a6752dfe788b8d994e155b3cd9778f
Merge: 0953cac a06cc29
Author: Eugen Konkov
Date:   Sat Oct 1 00:54:18 2016 +0300

    Merge branch 'redesign_interactions' into clean_api

Aktualizacja

Lub tylko jedno polecenie:

git log c0118fa..HEAD --ancestry-path --merges --oneline --color | tail -n 1

git branch --contains <ref>to najbardziej oczywiste polecenie „porcelany”, aby to zrobić. Jeśli chcesz zrobić coś podobnego tylko z poleceniami „hydraulika”:

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

(crosspost z tej odpowiedzi SO )

khichar.anil opisał większość tego w swojej odpowiedzi.

Właśnie dodam flagę, która usunie tagi z listy nazw wersji. To daje nam:

git name-rev --name-only --exclude=tags/* $SHA

Opcja biedny człowiek jest użycie narzędzia tig¹ na HEAD, szukać zatwierdzenia, a następnie wizualnie śledzić linię od tego zobowiązać z powrotem aż do scalającej widać. Domyślny komunikat o scaleniu powinien określać, gdzie gałąź zostanie scalona :)

¹ Tig to oparty na ncurses interfejs tekstowy dla Git. Działa głównie jako przeglądarka repozytorium Git, ale może także pomagać w stopniowaniu zmian dla zatwierdzenia na poziomie porcji i działać jako pager dla danych wyjściowych z różnych poleceń Git.

W ramach eksperymentu wykonałem przechwycenie po zatwierdzeniu, które przechowuje informacje o aktualnie wyewidencjonowanej gałęzi w metadanych zatwierdzenia. Zmodyfikowałem też nieco gitk, aby pokazać te informacje.

Możesz to sprawdzić tutaj: https://github.com/pajp/branch-info-commits

Mam do czynienia z tym samym problemem ( potok Jenkins multibranch) - posiadanie tylko informacji o zatwierdzeniach i próba znalezienia nazwy oddziału, z którego pochodziło to zatwierdzenie. Musi działać dla zdalnych oddziałów, lokalne kopie nie są dostępne.

Z tym pracuję:

git rev-parse HEAD | xargs git name-rev

Opcjonalnie możesz usunąć dane wyjściowe:

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

Myślę, że ktoś powinien zmierzyć się z tym samym problemem, który nie może znaleźć gałęzi, chociaż tak naprawdę istnieje w jednej gałęzi.

Lepiej wyciągnij wszystko najpierw:

git pull --all

Następnie wykonaj wyszukiwanie oddziału:

git name-rev <SHA>

lub:

git branch --contains <SHA>

Jeśli OP próbuje ustalić historię , przez którą przeszedł oddział podczas tworzenia konkretnego zatwierdzenia („dowiedz się, z jakiej gałęzi pochodzi zatwierdzenie, biorąc pod uwagę jego wartość skrótu SHA-1”), to bez ponownego logowania nie ma żadnych rekordy w bazie danych obiektów Git, które pokazują, która nazwana gałąź była powiązana z jaką historią zatwierdzania.

(Opublikowałem to jako odpowiedź w odpowiedzi na komentarz).

Mam nadzieję, że ten skrypt ilustruje mój punkt widzenia:

rm -rf /tmp/r1 /tmp/r2; mkdir /tmp/r1; cd /tmp/r1
git init; git config user.name n; git config user.email e@x.io
git commit -m"empty" --allow-empty; git branch -m b1; git branch b2
git checkout b1; touch f1; git add f1; git commit -m"Add f1"
git checkout b2; touch f2; git add f2; git commit -m"Add f2"
git merge -m"merge branches" b1; git checkout b1; git merge b2
git clone /tmp/r1 /tmp/r2; cd /tmp/r2; git fetch origin b2:b2
set -x;
cd /tmp/r1; git log --oneline --graph --decorate; git reflog b1; git reflog b2;
cd /tmp/r2; git log --oneline --graph --decorate; git reflog b1; git reflog b2;

Dane wyjściowe pokazują brak jakiegokolwiek sposobu, aby dowiedzieć się, czy zatwierdzenie z 'Add f1' pochodziło z gałęzi b1 czy b2 ze zdalnego klonu / tmp / r2.

(Ostatnie wiersze wyniku tutaj)

+ cd /tmp/r1
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: merge b2: Fast-forward
086c9ce b1@{1}: commit: Add f1
18feb84 b1@{2}: Branch: renamed refs/heads/master to refs/heads/b1
18feb84 b1@{3}: commit (initial): empty
+ git reflog b2
f0c707d b2@{0}: merge b1: Merge made by the 'recursive' strategy.
80c10e5 b2@{1}: commit: Add f2
18feb84 b2@{2}: branch: Created from b1
+ cd /tmp/r2
+ git log --oneline --graph --decorate
*   f0c707d (HEAD, origin/b2, origin/b1, origin/HEAD, b2, b1) merge branches
|\
| * 086c9ce Add f1
* | 80c10e5 Add f2
|/
* 18feb84 empty
+ git reflog b1
f0c707d b1@{0}: clone: from /tmp/r1
+ git reflog b2
f0c707d b2@{0}: fetch origin b2:b2: storing head

TL; DR:

Użyj poniższej instrukcji, jeśli zależy Ci na statusach wyjścia z powłoki:

• branch-current - nazwa bieżącego oddziału
• branch-names - czyste nazwy gałęzi (jedna na linię)
• branch-name - Upewnij się, że zwrócona jest tylko jedna gałąź branch-names

Zarówno branch-namei branch-nameszaakceptować commit jako argumentu, i domyślnie HEADjeśli jej nie podano.

Aliasy przydatne w skryptach

branch-current = "symbolic-ref --short HEAD"  # https://stackoverflow.com/a/19585361/5353461
branch-names = !"[ -z \"$1\" ] && git branch-current 2>/dev/null || git branch --format='%(refname:short)' --contains \"${1:-HEAD}\" #"  # https://stackoverflow.com/a/19585361/5353461
branch-name = !"br=$(git branch-names \"$1\") && case \"$br\" in *$'\\n'*) printf \"Multiple branches:\\n%s\" \"$br\">&2; exit 1;; esac; echo \"$br\" #"

Zatwierdź dostępny tylko z jednego oddziału

% git branch-name eae13ea
master
% echo $?
0

• Dane wyjściowe to STDOUT
• Wartość wyjściowa to 0.

Zobowiązanie osiągalne z wielu oddziałów

% git branch-name 4bc6188
Multiple branches:
attempt-extract
master%
% echo $?
1

• Dane wyjściowe są do STDERR
• Wartość wyjściowa to 1.

Ze względu na status wyjścia można je bezpiecznie zbudować. Na przykład, aby użyć pilota do pobierania:

remote-fetch = !"branch=$(git branch-name \"$1\") && git config branch.\"$branch\".remote || echo origin #"

Aby znaleźć oddział lokalny:

grep -lR YOUR_COMMIT .git/refs/heads | sed 's/.git\/refs\/heads\///g'

Aby znaleźć zdalną gałąź:

grep -lR $commit .git/refs/remotes | sed 's/.git\/refs\/remotes\///g'

Oprócz przeszukiwania całego drzewa, dopóki nie znajdziesz pasującego skrótu, nie.