2010-03-14 12 views
33

Tło: Korzystam z zautomatyzowanego systemu kompilacji, który jako wynik ma mieszanie git, a także nazwę oddziału, w którym znajduje się ten skrót, i tworzy go. Jednak system budujący używa samego skrótu, aby sprawdzić kod i zbudować go - po prostu przechowuje nazwę gałęzi, jak podano, w metadanych DB kompilacji.Jak ustalić, czy dany skrót hasha istnieje w danej gałęzi?

Martwię się, że programiści przypadkowo podadzą niewłaściwe nazwy oddziałów po uruchomieniu kompilacji, powodując zamieszanie, gdy ludzie przeglądają historię kompilacji.

Jak więc potwierdzić, przed przekazaniem nazwy skrótu i ​​nazwy do systemu kompilacji, że dany skrót ma faktycznie pochodzić z podanej gałęzi?

+3

dlaczego potrzebujesz nazwy oddziału? wydaje się dodatkową, nieprzydatną informacją dla systemu kompilacji. I tak naprawdę nie widzę, w jaki sposób byłoby to przydatne dla logów budujących czytanie programisty. – hasen

+0

Potrzebowałbyś nazwy oddziału w przypadku, gdyby twój workflow miał, nie wiem, rozwinięty i główny oddział używany do wdrożenia i chcesz wiedzieć, czy zatwierdzenia dostały się do jakiegoś konkretnego? Przy okazji, proszę przyjąć prawdziwą odpowiedź. –

+0

@Pinko Myślę, że wybrana odpowiedź powinna być [ta] (https://stackoverflow.com/a/2444924/161278). Ponieważ ma o wiele więcej głosów i jest znacznie prostsza dzięki użyciu natywnej funkcjonalności git. –

Odpowiedz

10

Hmm, to użycie nazwy oddziału wydaje podejrzane. Podobnie jak w odpowiedzi Dustina, może istnieć wiele gałęzi zawierających zatwierdzenie. Dlaczego jedna z tych nazw jest lepsza od innej w tym celu?


Jeśli interesuje Cię tylko jedna konkretna gałąź, możesz obliczyć "podstawę scalenia" między gałęzią a zatwierdzeniem.

Na poniższych schematach zatwierdzenie do budowy to C, końcówka żądanego oddziału to T, a podstawa scalania jest oznaczona powyżej M.

  • Jeśli M równa C równa T, to commit budować to wierzchołek deklarowanym gałęzi.

       M 
           ↓ 
    o--o--o--o--o--x branch # x is both C and T 
    
  • Jeśli M równa C, wtedy czubek deklarowanym gałęzi jest potomkiem commit zbudować.

     M 
         ↓ 
    o--o--C--o--o--T branch 
    
  • Jeśli M równa T, a następnie zobowiązać się do budowania jest potomkiem wierzchołka deklarowanym gałęzi.

     M 
         ↓ 
    o--o--T   branch 
         \ 
         o--o--C 
    
  • Jeśli M równa się coś innego, wtedy C jest potomkiem jakiegoś przodka T.

     M 
         ↓ 
    o--o--o--o--o--T branch 
         \ 
         o--o--C 
    
  • Jeśli nie ma M, a następnie zobowiązać się do budowy nie jest związane z deklarowanym gałęzi.

    o--o--o--o--o--T branch 
    
    o--o--o--o--C 
    

Można zrobić to sprawdzić tak:

#!/bin/sh 

# Usage: is-ancestor-of <branch> <commit> 

if test $# -ne 2; then 
    echo "$0"': invalid arguments' 
    exit 128 
fi 
claimed_branch="$1" 
commit="$2" 

merge_base="$(git merge-base "$commit" "$claimed_branch")" && 
    test -n "$merge_base" && 
    test "$merge_base" = "$(git rev-parse --verify "$commit")" && 
    exit 0 

echo "$commit is not an ancestor of $claimed_branch" 1>&2 
exit 1 

Powyższy skrypt właściwie nie wymagają lub sprawdzić, że „oddział” argument jest oddział (może to być dowolny komisje ish). Aby upewnić się, że coś jest w rzeczywistości oddział, możesz użyć czegoś takiego:

#!/bin/sh 

# Usage: is-branch <branch> 

if test $# -ne 1; then 
    echo "$0"': invalid arguments' 
    exit 128 
fi 
branch="$1" 

# check various branch hierarchies, adjust as needed 
git show-ref --verify refs/heads/"$branch" || 
git show-ref --verify refs/remotes/"$branch" || { 
    echo "not a branch name: $branch" 1>&2 
    exit 1 
} 

więc można ich używać razem w celu sprawdzenia, że ​​coś jest gałęzią i że pewna popełnić jest w tej branży:

is-branch "$claimed_branch" && is-ancestor-of "$claimed_branch" "$commit_to_build" 
+0

Bardzo interesujące. +1 – VonC

+2

Prostsze rozwiązanie @ http://stackoverflow.com/a/2444924/292408 –

+6

Dlaczego do cholery zrobiłbyś to, gdy git ma wbudowane lepsze rozwiązanie? Dlaczego, na Boga, ta śmiesznie pokrętna odpowiedź została zaakceptowana, gdy nie jest najwyraźniej najlepsza? Zmarnowałem czas przesiewając to, zamiast przewijać do odpowiedzi, która powinna znajdować się na górze. Wow ... –

1

Możliwym zakaz rozwiązanie byłoby przeanalizować wynik:

$ git reflog show myBranch 

i sprawdzić, czy jest w nim krzyżyka.

C:\Prog\Git\tests\rep\main>git reflog show patches 
786a190 [email protected]{0}: rebase finished: refs/heads/patches onto 74630b983db476c323b1d3f6771e57484551240e 
8448d0f [email protected]{1}: master~1: updating HEAD 
74630b9 [email protected]{2}: commit: test2 
1e73e36 [email protected]{3}: branch: Created from master 

trzymam to jako odpowiedź Wiki do zapamiętania Igor Zevaka i Chris Johnsen „s komentarze:

Oby praca po klonie?
Dość pewny, że twój reflog zaczyna się po sklonowaniu pilota. Więc jeśli oddział miał zatwierdzenie przed klonem, nie wyświetliłby się w reflogie.

Występują również problemy z popychaniem, rozgałęzianiem, pobieraniami (dla gałęzi "zdalnego śledzenia") i ciągnięciami (typu scalania lub rebase), w których tylko nowe zatwierdzenie końcówki kończy się reflogiem.
Również reflogi są domyślnie wyłączone w repozytoriach nagich (najczęstsze miejsce docelowe naciśnięć).
Również, jeśli "oszustwo" jest problemem, jest to tylko kwestia edytowania pliku tekstowego w celu dodania lub usunięcia wpisów do rejestru, ale jest to trudniejsza próba zmiany samego wykresu historii.

+0

Czy to działa po klonie? Jestem pewien, że twój reflog zaczyna się po sklonowaniu pilota. Więc jeśli oddział miał zatwierdzenie przed klonem, nie wyświetliłby się w reflogie. –

+0

Dobrze, @Igor Zevaka. Występują również problemy z popychaniem i rebazami (gdzie tylko nowe zatwierdzenie końcówki kończy się reflogiem). Również reflogi są domyślnie wyłączone w repozytoriach nagich (najczęstsze miejsce docelowe naciśnięć). Ponadto, jeśli "oszustwo" jest problemem, jest to tylko kwestia edytowania pliku tekstowego w celu dodania lub usunięcia wpisów do rejestru, ale jest to trudniejsza próba zmiany samego wykresu historii. –

114

Można zapytać git branch bezpośrednio których gałęzie zawierają popełnić w pytaniu:

% git branch -a --contains 4f08c85ad 
* master 
    remotes/origin/bug_872 
    remotes/origin/bug_898 
    remotes/origin/master 
+5

Usuń opcję '-a' do listy z lokalnego oddziału Tylko – ismailsunni

+0

Można użyć konkretnej gałęzi zamiast' -a', np. 'rozwija gałąź $ git - zawiera 4f08c85ad' –

Powiązane problemy