5.3 Rozproszony Git - Utrzymywanie projektu

Jeżeli otrzymałeś poprawkę od kogoś, kto wygenerował ją za pomocą komendy git diff lub uniksowej diff, możesz zaaplikować ją za pomocą komendy git apply. Zakładając, że zapisałeś plik w /tmp/patch-ruby-client.patch, możesz go nałożyć w taki sposób:

Ta komenda zmodyfikuje pliki znajdujące się w obecnym katalogu. Jest ona prawie identyczna do komendy patch -p1 w celu nałożenia poprawki, ale jest bardziej restrykcyjna pod względem akceptowanych zmian. Obsługuje również dodawanie plików, usuwanie, oraz zmiany nazw jeżeli zostały zapisane w formacie git diff, czego komenda patch nie zrobi. Wreszcie, git apply ma zasadę "zaakceptuj lub odrzuć wszystko", gdzie albo wszystko jest zaakceptowane albo nic, a patch może częściowo nałożyć zmiany zostawiając projekt z niespójnym stanem. Komenda git apply jest z zasady bardziej restrykcyjna niż patch. Nie stworzy za Ciebie commita – po uruchomieniu, musisz zatwierdzić wprowadzone zmiany ręcznie.

Możesz również użyć git apply aby zobaczyć, czy poprawka nałoży się czysto zanim ją zaaplikujesz – jeżeli uruchomisz git apply --check z poprawką:

Jeżeli nie zostanie wygenerowany żaden komunikat, to poprawka wdroży się poprawnie. Ta komenda również kończy działanie z niezerowym statusem w przypadku błędu, możesz więc jeśli chcesz, możesz użyć jej w skryptach.

Jeżeli otrzymałeś poprawkę wygenerowaną przez użytkownika używającego Gita, który stworzył go za pomocą format-patch, Twoja praca będzie prostsza ponieważ poprawka zawiera już informacje o autorze oraz komentarz do zmiany. Jeżeli możesz, namawiaj swoich współpracowników aby używali format-patch zamiast diff do generowania dla Ciebie poprawek. Powinieneś móc użyć jedynie git apply dla takich poprawek.

Aby zaaplikować poprawkę wygenerowaną przez format-patch, użyj git am. Technicznie rzecz biorąc, git am został stworzony, aby odczytywać plik w formacie mbox, który jest prostym, tekstowym formatem zawierającym jedną lub więcej wiadomości e-mail w jednym pliku. Wygląda on podobnie do:

To są pierwsze linie z wyniku komendy format-patch, którą zobaczyłeś w poprzedniej sekcji. Jest to również poprawny plik w formacie mbox. Jeżeli ktoś poprawnie przesłał do Ciebie poprawkę za pomocą git send-email, możesz ją zapisać w formacie mbox, następnie wskazać git am ten plik, a Git zacznie aplikować wszystkie znalezione poprawki. Jeżeli używasz klienta pocztowego, który potrafi zapisać kilka wiadomości e-mail w formacie mbox, możesz zapisać serię poprawek do pliku i użyć git am aby jest nałożyć wszystkie poprawki za jednym zamachem.

Również, jeżeli ktoś wgrał poprawkę wygenerowaną poprzez format-patch do systemu zgłoszeń błędów lub czegoś podobnego, możesz zapisać lokalnie ten plik i potem przekazać go do git am, tak aby zaaplikować go:

Możesz zauważyć, że poprawka została zaaplikowana bez problemu i została automatycznie zatwierdzona. Informacje o autorze zostały pobrane z wiadomości e-mail z nagłówków From i Date, a treść komentarz została pobrana z tematu i treści (przed poprawką) e-maila. Na przykład, jeżeli ta poprawka została zaaplikowana z pliku mbox, który przed chwilą pokazaliśmy, to wygenerowany commit będzie wyglądał mniej więcej tak:

Linie zaczynające się od Commit pokazują osobę która zaaplikowała poprawkę oraz czas kiedy to zrobiła. Linie rozpoczynające się od Author pokazują osobę która stworzyła poprawkę wraz z dokładną datą.

Jednak możliwa jest również sytuacja, w której poprawka nie zostanie bez problemów nałożona. Być może Twoja gałąź zbyt mocno się zmieniła, w stosunku do gałęzi, na której poprawka została stworzona, albo zależna jest ona od innej poprawki, której jeszcze nie nałożyłeś. W takiej sytuacji komenda git am zakończy się błędem i zapyta co robić dalej:

Ta komenda zaznacza pliku z którymi miała problemy, podobnie do konfliktów występujących podczas komend merge lub rebase. Rozwiązujesz takie sytuacja również analogicznie – zmień plik w celu rozwiązania konfliktu, dodaj do przechowalni nowe pliki i następnie uruchom git am --resolved aby kontynuować działanie do następnej poprawki:

Jeżeli chcesz aby Git spróbował w bardziej inteligentny sposób rozwiązać konflikty, dodaj opcję -3 do komendy, która daje Gitowi możliwość spróbowania trójstronnego łączenia. Opcja ta nie jest domyślnie włączona, ponieważ nie działa poprawnie w sytuacji gdy w twoim repozytorium nie ma commitu, na którym bazuje poprawka. Jeżeli go masz – jeżeli poprawka bazowała na publicznym commicie – to dodanie -3 zazwyczaj pozwala na dużo mądrzejsze zaaplikowanie konfliktującej poprawki:

W tym przypadku, ta poprawka została już zastosowana. Bez podanej opcji -3 wyglądało to na konflikt.

Jeżeli włączasz większą liczbę poprawek z pliku mbox, możesz użyć komendy am w trybie interaktywnym, który zatrzymuje się na każdej poprawce, którą znajdzie, i pyta czy chcesz ją zastosować:

Jest to całkiem dobre jeżeli masz zapisaną większą liczbę poprawek, ponieważ możesz najpierw zobaczyć poprawkę jeżeli nie pamiętasz do czego była, lub nie aplikować jej jeżeli już to zrobiłeś.

Kiedy wszystkie poprawki zostaną wgrane i commitnięte w Twojej gałęzi, możesz zastanowić się w jaki sposób i czy chcesz integrować je do jednej z głównych gałęzi.

Jednym z prostszych przepływów pracy jest scalenie zmian z twoją gałęzią master. W tym scenariuszu, posiadasz gałąź master, która zawiera stabilny kod. Kiedy masz zmiany w jednej z gałęzi tematycznych które wykonałeś, lub ktoś Ci przesłał a Ty je zweryfikowałeś, scalasz je z gałęzią master, usuwasz gałąź i kontynuujesz pracę. Jeżeli mielibyśmy repozytorium ze zmianami w dwóch gałęziach ruby_client oraz php_client (zob. Historia zmian z kilkoma gałęziami tematycznymi.) i mielibyśmy scalić najpierw ruby_client, a w następnej kolejności php_client, to Twoja historia zmian wyglądała by podobnie do Po scaleniu gałęzi tematycznej..

To jest prawdopodobnie najprostszy schemat pracy, ale jest on również problematyczny jeżeli masz do czynienia z dużymi repozytoriami lub projektami.

Jeżeli masz większą ilość programistów lub większy projekt, będziesz chciał pewnie używał przynajmniej dwufazowego cyklu scalania. W tym scenariuszu, posiadasz funkcjonujące już długo dwie gałęzie master oraz develop, z których master jest aktualizowana tylko z bardzo stabilnymi zmianami, a cały nowy kod jest włączany do gałęzi develop. Regularnie wysyłasz ("push") obie te gałęzie do publicznego repozytorium. Za każdym razem gdy masz nową gałąź tematyczną do zintegrowania (Przed scaleniem gałęzi tematycznej.), włączasz ją do develop (Po scaleniu gałęzi tematycznej.); a kiedy tagujesz kolejną wersję, przesuwasz master za pomocą fast-forward o punktu w którym jest gałąź develop (Po utworzeniu kolejnej wersji.).

W ten sposób, kiedy ludzie klonują Twoje repozytorium, mogą albo pobrać master aby zbudować najnowszą stabilną wersję i utrzymywać ją uaktualnioną, lub mogą pobrać develop która zawiera mniej stabilne zmiany. Możesz rozbudować tą koncepcję, poprzez dodanie gałęzi służącej do integracji. Wtedy jeżeli kod w znajdujący się w niej jest stabilny i przechodzi wszystkie testy, scalasz ją do gałęzi develop; a jeżeli ta okaże się również stabilna, przesuwasz master za pomocą fast-forward.

Projekt Gita ma cztery długo funkcjonujące już gałęzie: master, next, pu (z ang. proposed updates, czyli proponowane zmiany) dla nowych funkcjonalności, oraz maint do wprowadzania poprawek z nowszej wersji na starszą. Kiedy nowe zmiany są dostarczone przez deweloperów, zbierane są do gałęzi tematycznych w repozytorium opiekuna, w sposób podobny do tego który opisałem (zob. Zarządzanie złożoną serią równoczesnych zmian w gałęziach tematycznych.). W tym momencie, są one weryfikowane i sprawdzane czy mogą być użyte, lub czy nadal wymagają dalszych prac. Jeżeli są gotowe, są włączona do next, a ta gałąź jest wypychana dalej, tak aby każdy mógł wypróbować nowe funkcjonalności.

Jeżeli funkcjonalność potrzebuje jeszcze kolejnych zmian, są one włączane do gałęzi pu. Kiedy okaże się, że cały kod działa już poprawnie, zmiany są włączane do master oraz przebudowywane włącznie ze zmianami z gałęzi next, które nie znalazły się jeszcze w master. Oznacza to, że master praktycznie zawsze przesuwa się do przodu, next tylko czasami ma zmienianą bazę poprzez "rebase", a pu najczęściej z nich może się przesunąć w innym kierunku

Z chwilą, gdy gałąź tematycznie zostanie włączona do master, jest usuwana z repozytorium. Projekt Gita ma również gałąź maint, która jest tworzona z ostatniej wersji, w celu dostarczania zmian w sytuacji gdy trzeba wydać wersję poprawkową. Dlatego kopiując repozytorium Gita masz cztery gałęzie, w których możesz zobaczyć projekt w różnych stadiach rozwoju, w zależności od tego jak stabilny kod chcesz używać, lub nad którym pracować; a opiekun ma ułatwiony przepływ zmian pomagający panować nad nowymi zmianami.

Część opiekunów woli używać rebase lub cherry-pick w celu włączania zmian w gałęzi master, zamiast przy użyciu merge, aby zachować bardziej liniową historię. Kiedy masz zmiany w gałęzi tematycznej i decydujesz się zintegrować je, przenosisz gałąź i uruchamiasz rebase aby nałożyć zmiany na górze swojej gałęzi master (lub develop, czy innej). Jeżeli to zadziała poprawnie, możesz przesunąć swoją gałąź master i otrzymasz praktycznie liniową historię.

Drugim sposobem na przeniesienie zmian z jednej gałęzi do drugiej jest zrobienie tego za pomocą komendy cherry-pick. Komenda ta jest podobna do rebase, ale dla pojedynczej zmiany. Pobiera ona zmianę która została wprowadzona i próbuje ją ponownie nałożyć na gałąź na której obecnie pracujesz. Jest to całkiem przydatne, w sytuacji gdy masz większą ilość zmian w gałęzi tematycznej, a chcesz zintegrować tylko jedną z nich, lub jeżeli masz tylko jedną zmianę w gałęzi i wolisz używać cherry-pick zamiast rebase. Dla przykładu, załóżmy że masz projekt, który wygląda jak poniżej:

Jeżeli chcesz pobrać zmianę e43a6 do swojej gałęzi master, możesz uruchomić:

To pobierze tylko zmiany z commita e43a6, ale otrzyma nową sumę SHA-1, ze względu na nową datę nałożenia. Teraz Twoja historia zmian wygląda tak:

Teraz możesz usunąć swoją gałąź tematyczną oraz zmiany, których nie chciałeś pobierać.

If you’re doing lots of merging and rebasing, or you’re maintaining a long-lived topic branch, Git has a feature called "rerere" that can help.

Rerere stands for "reuse recorded resolution" – it’s a way of shortcutting manual conflict resolution. When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there’s a conflict that looks exactly like one you’ve already fixed, it’ll just use the fix from last time, without bothering you with it.

This feature comes in two parts: a configuration setting and a command. The configuration setting is rerere.enabled, and it’s handy enough to put in your global config:

Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future.

If you need to, you can interact with the rerere cache using the git rerere command. When it’s invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if rerere.enabled is set to true). There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. We will cover rerere in more detail in Rerere.