Podziały i gałęzie nadrzędne Git: samouczek i ciekawa wskazówka

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ędnagałąź zdalna — ta druga jest strażnikiem projektu lub źródłem rzetelnych informacji, 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:

1git remote -v
2
3origin  git@bitbucket.org:my-user/some-project.git (fetch)
4origin  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:

1git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git

Upewnij się, że zdalna lokalizacja została prawidłowo dodana:

1git remote -v
2
3origin    git@bitbucket.org:my-user/some-project.git (fetch)
4origin    git@bitbucket.org:my-user/some-project.git (push)
5upstream  git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch)
6upstream  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)

1git 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:

1git checkout main
2git 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:

1git checkout -b feature-x
2
3#some work and some commits happen
4#some time passes
5
6git fetch upstream
7git 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:

1git push origin feature-x

1git 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 fetchgit 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:

1nick-macbook-air:~/dev/projects/stash[1|94]$

A to musisz dodać do swojego pliku .bashrc lub jego odpowiednika — tylko jedną funkcję:

1function ahead_behind {
2    curr_branch=$(git rev-parse --abbrev-ref HEAD);
3    curr_remote=$(git config branch.$curr_branch.remote);
4    curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);
5    git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';
6}

1export 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:

1curr_branch=$(git rev-parse --abbrev-ref HEAD);

Tworzymy zmienną dla zdalnej lokalizacji, do której odwołuje się bieżąca gałąź:

1curr_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 [ / ]):

1curr_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:

1git 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!