3.5 Gałęzie Gita - Gałęzie zdalne

Kiedy chcesz podzielić się ze światem gałęzią, potrzebujesz wypchnąć ją na serwer, do którego posiadasz uprawnienia zapisu. Twoje lokalne gałęzie nie są automatycznie synchronizowane z serwerami do których zapisujesz dane - musisz jawnie wypchnąć gałęzie które chcesz udostępnić. Dzięki temu możesz używać lokalnych gałęzi których nie chcesz udostępniać do pracy, i wypychać tylko gałęzie nad którymi współpracujesz.

Jeśli posiadasz gałąź serverfix nad którą chcesz pracować z innymi, możesz wypchnąć ją w taki sam sposób, jak wypchnąłeś swoją pierwszą gałąź. Wykonaj git push (nazwa zdalnego repozytorium) (nazwa gałęzi):

Jest to tak naprawdę skrót. Git automatycznie rozwija nazwę gałęzi serverfix do refs/heads/serverfix:refs/heads/serverfix, co oznacza “Weź moją lokalną gałąź serverfix i wypchnij ją aby zaktualizować zdalną gałąź serverfix.” W szczegółach zajmiemy się częścią refs/heads/ w rozdziale Mechanizmy wewnętrzne w Git, aczkolwiek możesz ją teraz pominąć. Możesz również wykonać git push origin serverfix:serverfix, co wykonuje to samo – mówiąc, “Weź serverfix i stwórz zdalnie serverfix.” Możesz wykorzystać ten format do wypchnięcia gałęzi lokalnej na gałąź zdalną która nazywa się inaczej. Jeśli nie chcesz nazywać jej serverfix na serwerze, możesz zamiast tego wykonać git push origin serverfix:awesomebranch aby wypchnąć lokalną gałąź serverfix na gałąź awesomebranch w projekcie zdalnym.

Kiedy współpracownicy pobiorą następnym razem zmiany z serwera, otrzymają referencję do wersji serverfix na serwerze pod gałęzią origin/serverfix:

Ważnym jest że gdy pobierasz zmiany które przynoszą nowe gałęzie zdalne, nie posiadasz automatycznie ich lokalnych, edytowalnych kopii. Innymi słowy, w tym przypadku, nie posiadasz nowej gałęzi serverfix – posiadasz tylko wskaźnik do origin/serverfix którego nie możesz zmieniać. Aby scalić tę pracę z Twoją obecnie wybraną gałęzią, możesz wykonać git merge origin/serverfix. Jeśli chcesz swoją własną gałąź serverfix na której możesz pracować, możesz oprzeć ją o gałąź zdalną:

To daje gałąź lokalną na której można pracować, która rozpoczyna od miejsca, w którym znajduje się origin/serverfix.

Przełączenie się na gałąź lokalną z gałęzi zdalnej automatycznie tworzy coś, co nazywane jest “gałęzią śledzącą” (lub czasami “gałęzią upstream”). Gałęzie śledzące to lokalne gałęzie, które posiadają relację z gałęzią zdalną. Jesli jesteś na gałęzi śledzącej i wpiszesz git pull, Git automatycznie wie z którego serwera należy pobrać dane i zna gałąź którą należy scalić.

Kiedy klonujesz repozytorium, generalnie automatycznie tworzona jest gałąź master która śledzi origin/master. Aczkolwiek, możesz ustawić inne gałęzie śledzące jeśli chcesz – takie które śledzą inne, zdalne, lub nie śledzą gałęzi master. Najprostszym przypadkiem jest ten która zobaczyłeś przed chwilą, wykonując git checkout -b [gałąź] [źródłozdalne]/[gałąź]. Jest to dość powszechna operacja do której git dokłada skrót --track:

Aby ustawić gałąź lokalną z inną nazwą niż gałęzi zdalnej, możesz z łatwością wykorzystać pierwszą wersję z inną nazwą lokalnej gałęzi:

Teraz, Twoja gałąź lokalna sf będzie automatycznie pobierać zmiany z origin/servefix.

Jeśli masz już gałąź lokalną i chcesz ustawić jej śledzenie na gałąź zdalną z której właśnie pobrałeś zmiany, lub chcesz zmienić gałąź docelową którą śledzisz, możesz użyć opcji -u lub --set-upstream-to w git branch aby jawnie ustawić ją w dowolnym momencie.

Jeśli chcesz zobaczyć jakie gałęzie są śledzone, możesz wykorzystać opcję -vv w git branch. Spowoduje to wyświetlenie listy lokalnych gałęzi z większą ilością informacji, włączając w to jakie gałęzie są śledzone oraz czy gałąź lokalna jest przed, za, czy na równi z gałęzią zdalną.

Możemy tu zobaczyć że nasza gałąź iss53 śledzi origin/iss53 i jest “przed” o dwa, co oznacza że mamy dwa commity lokalnie które nie są wypchnięte na serwer. Możemy również zobaczyć że nasza gałąź master śledzi origin/master i jest aktualna. Następnie możemy zobaczyć że nasza gałąź serverfix śledzi gałąź server-fix-good na serwerze teamone i jest przed o trzy oraz za o jeden, co oznacza że jest commit na serwerze którego jeszcze nie scaliliśmy i trzy commity lokalnie których jeszcze nie wypchnęliśmy. Na koniec widzimy że nasza gałąź testing nie śledzi żadnej gałęzi zdalnej.

Ważnym jest że te cyfry oddają stan na moment ostatniego pobrania zmian z serwera. Komenda ta nie sprawdza serwerów, mówi jedynie co zostało zapamiętane na temat serwerów lokalnie. Jeśli chcesz być zupełnie na bieżąco, musisz pobrać dane ze wszystkich zdalnych źródeł tuż przed wykonaniem tego polecenia. Możesz to osiągnąć tak: $ git fetch --all; git branch -vv

Gdy komenda git fetch pobierze wszystkie zmiany z serwera których dotychczas nie miałeś lokalnie, nie zmienia ona tak naprawdę danych projektu. Pobiera ona jedynie dane i pozwala scalić je we własnym zakresie. Jednakże, istnieje komenda git pull która jest tak naprawdę komendą git fetch za którą jest wykonana natychmiast komenda git merge w większości przypadków. Jeśli masz gałąź śledzącą ustawioną tak jak przedstawiono w poprzedniej sekcji, poprzez jawne ustawienie jej lub utworzenie jej przez komendy clone lub checkout, git pull będzie sprawdzać jaki serwer i gałąź śledzi obecna gałąź, pobierze zmiany z tego serwera i spróbuje scalić tę zdalną gałąź.

Zazwyczaj jest lepiej po prostu użyć komend fetch i merge jawnie, przez wzgląd na to że magia git pull może być często myląca.

Załóżmy że skończyłeś pracę na gałęzią zdalną – powiedzmy że ty i Twoi współpracownicy zakończyliście pracę nad nową funkcją i scaliliście zmiany ze zdalną gałęzią główną master (lub jakąkolwiek inną na której znajduje się stabilna wersja kodu). Możesz usunąć zdalną gałąź wykorzystując opcję --delete w git push. Jeśli chcesz usunąć Twoją gałąź serverfix z serwera, możesz wykonać następującą komendę:

Najprościej mówiąc usuwa to wskaźnik z serwera. Serwer Git przechowuje dane przez jakiś czas zanim sprzątanie ruszy, więc jeśli usunięcie danych było przypadkowe, zazwyczaj jest łatwe do odzyskania.