[ Pobierz całość w formacie PDF ]
.A wszystko to wykonałeś za pomocą dwóch prostych poleceń branch i checkout.Ponieważ gałęzie w Gicie są tak naprawdę prostymi plikami, zawierającymi 40 znaków sumy kontrolnej SHA-1 zestawuzmian, na który wskazują, są one bardzo tanie w tworzeniu i usuwaniu.Stworzenie nowej gałęzi zajmuje dokładnie tyleczasu, co zapisanie 41 bajtów w pliku (40 znaków + znak nowej linii).Wyraznie kontrastuje to ze sposobem, w jaki gałęzie obsługuje większość narzędzi do kontroli wersji, gdzie z reguły w gręwchodzi kopiowanie wszystkich plików projektu do osobnego katalogu.Może to trwać kilkanaście sekund czy nawet minut, wzależności od rozmiarów projektu, podczas gdy w Gicie jest zawsze natychmiastowe.Co więcej, ponieważ wraz z każdymzestawem zmian zapamiętujemy jego rodziców, odnalezienie wspólnej bazy przed scaleniem jest automatyczniewykonywane za nas i samo w sobie jest niezwykle proste.Możliwości te pomagają zachęcić deweloperów do częstegotworzenia i wykorzystywania gałęzi.Zobaczmy, dlaczego ty też powinieneś. Podstawy rozgałęziania i scalaniaZajmijmy się prostym przykładem rozgałęziania i scalania używając schematu, jakiego mógłbyś użyć w rzeczywistej pracy.Wtym celu wykonasz następujące czynności:1.Wykonasz pracę nad stroną internetową.2.Stworzysz gałąz dla nowej funkcji, nad którą pracujesz.3.Wykonasz jakąś pracę w tej gałęzi.Na tym etapie otrzymasz telefon, że inny problem jest obecnie priorytetem i potrzeba błyskawicznej poprawki.Oto, co robisz:1.Powrócisz na gałąz produkcyjną.2.Stworzysz nową gałąz, by dodać tam poprawkę.3.Po przetestowaniu, scalisz gałąz z poprawką i wypchniesz zmiany na serwer produkcyjny.4.Przełączysz się na powrót do gałęzi z nową funkcją i będziesz kontynuować pracę.Podstawy rozgałęzianiaNa początek załóżmy, że pracujesz nad swoim projektem i masz już zatwierdzonych kilka zestawów zmian (patrz Rysunek 3-10).Zdecydowałeś się zająć problemem #53 z systemu śledzenia zgłoszeń, którego używa Twoja firma, czymkolwiek by on niebył.Dla ścisłości, Git nie jest powiązany z żadnym konkretnym systemem tego typu; tym niemniej ponieważ problem #53 todość konkretny temat, utworzysz nową gałąz by się nim zająć.Aby utworzyć gałąz i jednocześnie się na nią przełączyć,możesz wykonać polecenie git checkout z przełącznikiem -b:$ git checkout -b iss53Switched to a new branch "iss53"Jest to krótsza wersja:$ git branch iss53$ git checkout iss53Figure 3-11 pokazuje wynik.Pracujesz nad swoim serwisem WWW i zatwierdzasz kolejne zmiany.Każdorazowo naprzód przesuwa się także gałąz iss53,ponieważ jest aktywna (to znaczy, że wskazuje na nią wskaznik HEAD; patrz Rysunek 2-12):$ vim index.html$ git commit -a -m 'nowa stopka [#53]' Teraz właśnie otrzymujesz telefon, że na stronie wykryto błąd i musisz go natychmiast poprawić.Z Gitem nie musiszwprowadzać poprawki razem ze zmianami wykonanymi w ramach pracy nad iss35.Co więcej, nie będzie cię równieżkosztować wiele wysiłku przywrócenie katalogu roboczego do stanu sprzed tych zmian, tak, by nanieść poprawki na kod,który używany jest na serwerze produkcyjnym.Wszystko, co musisz teraz zrobić, to przełączyć się z powrotem na gałązmaster.Jednakże, nim to zrobisz, zauważ, że, jeśli Twój katalog roboczy lub poczekalnia zawierają niezatwierdzone zmiany, które sąw konflikcie z gałęzią, do której chcesz się teraz przełączyć, Git nie pozwoli ci zmienić gałęzi.Przed przełączeniem gałęzinajlepiej jest doprowadzić katalog roboczy do czystego stanu.Istnieją sposoby pozwalające obejść to ograniczenie(mianowicie schowek oraz poprawianie zatwierdzonych już zmian) i zajmiemy się nimi pózniej.Póki co zatwierdziłeśwszystkie swoje zmiany, więc możesz przełączyć się na swoją gałąz master:$ git checkout masterSwitched to branch "master"W tym momencie Twój katalog roboczy projektu jest dokładnie w takim stanie, w jakim był zanim zacząłeś pracę nadproblemem #53, więc możesz skoncentrować się na swojej poprawce.Jest to ważna informacja do zapamiętania: Gitresetuje katalog roboczy, by wyglądał dokładnie jak migawka zestawu zmian wskazywanego przez aktywną gałąz.Automatycznie dodaje, usuwa i modyfikuje pliki, by upewnić się, że kopia robocza wygląda tak, jak po ostatnichzatwierdzonych w niej zmianach.Masz jednak teraz do wykonania ważną poprawkę.Stwórzmy zatem gałąz, na której będziesz pracował do momentupoprawienia błędu (patrz Rysunek 3-13):$ git checkout -b 'hotfix'Switched to a new branch "hotfix"$ vim index.html$ git commit -a -m 'poprawiony adres e-mail'[hotfix]: created 3a0874c: "poprawiony adres e-mail"1 files changed, 0 insertions(+), 1 deletions(-)Możesz uruchomić swoje testy, upewnić się, że poprawka w gałęzi hotfix jest tym, czego potrzebujesz i scalić ją na powrót zgałęzią master, by następnie przenieść zmiany na serwer produkcyjny
[ Pobierz całość w formacie PDF ]