Close

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

Zdjęcie portretowe Nicoli Paolucciego
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
Bazy danych
materiały pokrewne

Jak przenieść pełne repozytorium Git

Logo Bitbucket
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.

Nicola Paolucci

Nicola is an all-round hacker who loves exploring and teaching bleeding edge technologies. He writes and talks about Git, development workflows, code collaboration and more recently about Docker. Prior to his current role as Developer Instigator at Atlassian he led software teams, built crowd sourcing applications for geo-spacial data, worked on huge e-commerce deployments. Little known facts about Nicola: he gesticulates a lot while speaking (being Italian), lives in Amsterdam and rides a Ducati.


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.

Ludzie współpracujący przy ścianie pełnej narzędzi

Blog Bitbucket

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Demonstracje funkcji z ekspertami Atlassian

Zobacz, jak Bitbucket Cloud współpracuje z Atlassian Open DevOps

Zapisz się do newslettera DevOps

Thank you for signing up