Podziały i gałęzie nadrzędne Git: samouczek i ciekawa wskazówka
Nicola Paolucci
Developer 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 upstream
Ogó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/main
Aby 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/main
Publikowanie 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-x
git push -f origin feature-x
Osobiś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 Server 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!
Obserwuj mnie (@durdn) i niesamowity zespół @Bitbucket, aby otrzymywać więcej informacji o DVCS.
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.