Odpowiedzi:
Dokumentacja dla Gerrit, w szczególności sekcja „Wypychanie zmian” , wyjaśnia, że wypychasz do „magicznego odniesienia refs/for/'branch'
za pomocą dowolnego narzędzia klienta Git”.
Poniższy obraz pochodzi z Intro to Gerrit . Kiedy naciskasz na Gerrita, robisz git push gerrit HEAD:refs/for/<BRANCH>
. Spowoduje to przeniesienie zmian do obszaru przejściowego (na diagramie „Oczekujące zmiany”). Gerrit tak naprawdę nie ma gałęzi o nazwie <BRANCH>
; to leży po stronie klienta git.
Wewnętrznie Gerrit ma własną implementację dla stosów Git i SSH. Pozwala to na dostarczenie „magicznych” odniesień refs/for/<BRANCH>
.
Po odebraniu żądania wypychania w celu utworzenia odwołania w jednej z tych przestrzeni nazw, Gerrit wykonuje własną logikę aktualizacji bazy danych, a następnie okłamuje klienta o wyniku operacji. Pomyślny wynik powoduje, że klient wierzy, że Gerrit stworzył odniesienie, ale w rzeczywistości Gerrit w ogóle go nie utworzył. [ Link - Gerrit, „Gritty Details” ].
Po udanej łatce (tj. Poprawka została przesłana do Gerrit, [umieszczona w strefie tymczasowej "Oczekujących zmian"], przejrzana i przejrzana), Gerrit wypycha zmianę z "Oczekujących zmian" do " Autorytatywne repozytorium ”, obliczające, do której gałęzi należy go wepchnąć, na podstawie magii, jaką zrobił, gdy popchnąłeś refs/for/<BRANCH>
. W ten sposób pomyślnie sprawdzone poprawki można pobrać bezpośrednio z odpowiednich gałęzi Authoritative Repository
.
Aby uniknąć konieczności pełnego określenia polecenia git push, możesz alternatywnie zmodyfikować plik konfiguracyjny git:
[remote "gerrit"]
url = https://your.gerrit.repo:44444/repo
fetch = +refs/heads/master:refs/remotes/origin/master
push = refs/heads/master:refs/for/master
Teraz możesz po prostu:
git fetch gerrit
git push gerrit
Tak jest według Gerrita
remote.origin.push
zamiast wpisywać / wklejać za każdym razem!
git fetch
i git push
ze wspomnianą wyżej konfiguracją @DavidDoria.