Podziały i gałęzie nadrzędne Git: samouczek i ciekawa wskazówka
NICOLA PAOLUCCI
Deweloper Advocate
Podział projektów w celu wprowadzania własnych zmian pozwala łatwo zintegrować własną pracę. Natomiast jeśli nie wysyłasz tych zmian z powrotem do gałęzi nadrzędnej — co oznacza odesłanie ich z powrotem do repozytorium nadrzędnego — istnieje ryzyko utraty ich śledzenia i powstania rozbieżnych wierszy w repozytorium. Aby się upewnić, że wszyscy współpracownicy korzystają z tej samej lokalizacji, musisz znać pewne zasady interakcji podziałów Git z gałęziami nadrzędnymi Git. W tym wpisie na blogu przedstawię podstawowe informacje, istotne kwestie, a nawet dam Ci świetną wskazówkę, która ułatwi Ci rozpoczęcie pracy.
Gałąź nadrzędna Git: bądź na bieżąco i wnoś swój wkład
Zacznę od szczegółów typowej konfiguracji i najbardziej podstawowego przepływu pracy związanego z interakcją z repozytoriami nadrzędnymi.
W standardowej konfiguracji zwykle istnieje źródłowa i nadrzędna gałąź zdalna — ta druga jest strażnikiem projektu lub źródłem prawdy, do którego chcesz wnosić swój wkład.
Najpierw upewnij się, że skonfigurowano już gałąź zdalną dla repozytorium nadrzędnego, a także dla repozytorium źródłowego:
git remote -v
origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)Jeśli nie masz repozytorium nadrzędnego, możesz je łatwo dodać przy użyciu polecenia remote:
git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git
materiały pokrewne
Jak przenieść pełne repozytorium Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Upewnij się, że zdalna lokalizacja została prawidłowo dodana:
git remote -v
origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (push)Teraz możesz pobrać najnowsze zmiany z repozytorium nadrzędnego przy użyciu polecenia fetch. Powtórz tę czynność za każdym razem, gdy chcesz pobrać aktualizacje:
(Jeśli projekt ma tagi, które nie zostały scalone z gałęzią główną, możesz również użyć polecenia git fetch upstream --tags)
git fetch upstreamOgólnie rzecz biorąc, warto zachować lokalną gałąź główną jako dokładne odbicie lustrzane nadrzędnej gałęzi głównej i pracować w gałęziach funkcji, ponieważ mogą stać się później pull requestami.
Na tym etapie nie ma znaczenia, czy użyjesz polecenia merge czy rebase, ponieważ wynik będzie zwykle taki sam. Użyjmy polecenia merge:
git checkout main
git merge upstream/mainAby udostępnić swoją pracę opiekunom gałęzi nadrzędnej, należy utworzyć gałąź funkcji od gałęzi głównej. Gdy będzie gotowa, wypchnij ją do zdalnego repozytorium.
Zamiast tego możesz również użyć polecenia rebase, a następnie polecenia merge, aby upewnić się, że w gałęzi nadrzędnej znajduje się czysty zestaw commitów (najlepiej jeden) do oceny:
git checkout -b feature-x
#some work and some commits happen
#some time passes
git fetch upstream
git rebase upstream/mainPublikowanie przy użyciu podziału Git
Po wykonaniu powyższych czynności opublikuj swoją pracę w zdalnym podziale projektu przy użyciu prostego polecenia push:
git push origin feature-xgit push -f origin feature-xOsobiście wolę zachować jak najczystszą historię i wybrać opcję trzecią, ale poszczególne zespoły mają różne przepływy pracy. Uwaga: te czynności należy wykonywać tylko podczas pracy z własnym podziałem. Przepisywanie historii współdzielonych repozytoriów i gałęzi to coś, czego NIGDY nie należy robić.
Porada dnia: liczba wersji do przodu/tyłu w wierszu polecenia
Po wykonaniu polecenia fetch git status wyświetla liczbę commitów do przodu/tyłu względem zsynchronizowanej gałęzi zdalnej. Czy nie byłoby miło, gdyby można było zobaczyć te informacje w niezawodnym wierszu polecenia? Tak myślałem, dlatego przygotowałem rozwiązanie w postaci skryptu bash.
Oto jak będzie wyglądał w wierszu poleceń po skonfigurowaniu:
nick-macbook-air:~/dev/projects/stash[1|94]$A to musisz dodać do swojego pliku .bashrc lub jego odpowiednika — tylko jedną funkcję:
function ahead_behind {
curr_branch=$(git rev-parse --abbrev-ref HEAD);
curr_remote=$(git config branch.$curr_branch.remote);
curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);
git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';
}export PS1="\h:\w[\$(ahead_behind)]$"Sposób działania
Dla tych, którzy lubią szczegóły i wyjaśnienia, oto jak to działa:
Nadajemy symboliczną nazwę bieżącemu elementowi HEAD, tj. bieżącej gałęzi:
curr_branch=$(git rev-parse --abbrev-ref HEAD);Tworzymy zmienną dla zdalnej lokalizacji, do której odwołuje się bieżąca gałąź:
curr_remote=$(git config branch.$curr_branch.remote);Tworzymy zmienną gałęzi, do której ta lokalizacja zdalna ma zostać scalona (za pomocą prostego triku w systemach Unix polegającego na odrzucaniu wszystkiego do ostatniego ukośnika włącznie [ / ]):
curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);Teraz mamy wszystko, czego potrzebujemy, aby uzyskać informację o liczbie commitów do przodu/tyłu:
git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';Użyjemy starego polecenia systemu Unix tr, aby przekształcić znak TAB na separator |.
Rozpoczęcie pracy z git upstream
Jest to podstawowy przewodnik po git upstream, z którego dowiesz się, jak skonfigurować git upstream, utworzyć nową gałąź, pobierać zmiany, publikować przy użyciu git fork, a także uzyskasz świetną wskazówkę dotyczącą uzyskiwania informacji na temat liczby commitów do przodu/tyłu względem zdalnej gałęzi.
Bitbucket Data Center obejmuje synchronizację podziału, która zwalnia programistę z konieczności uzyskiwania informacji o zmianach w podziałach, a Bitbucket Cloud zapewnia łatwą, jednoetapową synchronizację. Wypróbuj te funkcje!
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
