Czym są gałęzie w systemie Git?

W systemie kontroli wersji Git każda zatwierdzona zmiana projektu jest podpisana unikatowym identyfikatorem, a dokładnie: sumą kontrolnąsuma kontrolnasumą kontrolną. Dzięki temu możemy śledzić historię zmian wprowadzonych do projektu. Dodanie jakiejkolwiek poprawki jest powiązane z poprzednią zmianą: powstaje w ten sposób relacja typu rodzic‑dziecko.

Przedstawimy ciąg zmian wprowadzonych do projektu. Kolejne wersje na rysunkach oznaczymy symbolami , , , .

Zwrot strzałek na przedstawionych rysunkach wskazuje na rodzica, od którego pochodzi dany commit.

R1NEAZwDgXIMg
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Między obiektami pokazanymi na rysunku zachodzą następujące relacje:

  • jest rodzicem ,

  • jest rodzicem i dzieckiem ,

  • jest dzieckiem .

Wprowadzając zmiany do projektu, tworzymy strukturę drzewa. Poszczególne wersje projektu, w których zmiany zostały zatwierdzone, nazywamy commitami.

Poświęćmy kilka słów terminowi commit. Jest to bowiem jeden z przypadków, w których język naturalny nie nadąża za technologią. W języku polskim nie powstał na razie zwięzły, a zarazem oddający istotę rzeczy odpowiednik tego słowa. Chcąc nie chcąc, użyjemy pojęcia commit, ilekroć będziemy mieli na myśli zatwierdzoną wersję projektu.

W powyższym przykładzie mamy do czynienia z prostą liniową strukturą bez rozgałęzień.

Gałąź (branch) w systemie Git jest ciągiem kolejnych wersji projektu, do których wprowadziliśmy zmiany (czyli są to następujące po sobie commity).

R1bqEmTtUQ6Gw
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Domyślną gałęzią w systemie Git jest master. Dodatkowo istnieje wskaźnik HEADHEADHEAD. Informuje on, która wersja projektu jest obecnie wczytana do katalogu roboczego – są to pliki, nad którymi aktualnie pracujesz. Wskaźnik ten automatycznie przesuwa się wraz ze zmianami wprowadzanymi do projektu (czyli wraz z powstawaniem kolejnych commitów). W naszym przypadku wskaźnik HEAD pokazuje commit należący do gałęzi master.

Utworzenie nowej gałęzi sprowadza się do utworzenia nowego wskaźnika. Nie powstaje natomiast dodatkowa kopia istniejącego już projektu – jest to rozwiązanie bardzo efektywne.

Po utworzeniu nowej gałęzi można powiedzieć, że mamy dwie niezależne wersje projektu. Zmiany wprowadzone w jednej gałęzi nie wpływają na pozostałe gałęzie. Jeśli zajdzie taka potrzeba, gałęzie można połączyć.

Częstą praktyką przy pracy z systemem Git jest rozwijanie projektu na gałęzi o nazwie - develop. Gdy dana grupa zmian zostanie przetestowana oraz zatwierdzona, włącza się ją do głównej gałęzi.

R7ZrhHSHXa8hg
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Wprowadzając zmiany w obu wersjach projektu, zaobserwujemy powstanie rozgałęzienia. Utworzyły się dwie linie projektu, czyli odrębne gałęzie.

RR562GFFDA4xn
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Do czego używane są gałęzie?

Wykorzystywanie gałęzi jest przydatne zarówno podczas pracy zespołowej, jak i wtedy, gdy samodzielnie pracujesz z repozytorium.

Istnieje kilka technik pracy z wykorzystaniem gałęzi. Obowiązujące w nich zasady ustalają członkowie zespołu. Przykładowo, w jednej gałęzi (zazwyczaj master) utrzymywany jest zawsze aktualny, działający projekt. Gdy chcemy wprowadzić do niego zmiany, tworzymy nową gałąź i z nią właśnie pracujemy. Gdy uznamy, że osiągnęliśmy wyznaczony cel, włączamy wprowadzone zmiany do gałęzi głównej.

W praktyce utworzenie nowej gałęzi można wykorzystać m.in. przy:

  1. Dodawaniu nowych funkcji do projektu. Tworzysz nową gałąź, w której wprowadzasz nowe elementy do działającej wersji programu. W głównej gałęzi istnieje wciąż projekt w postaci niezmienionej, do której w razie konieczności można się cofnąć. Gdy skończysz pracę nad zmianami, łączysz obie gałęzie.

  2. Wprowadzaniu poprawek. Jest to przykład bardzo podobny do poprzedniego. Poprawki wprowadzane są w osobnej gałęzi, a po ich zatwierdzeniu gałęzie są łączone.

  3. Eksperymentach. Gdy chcesz coś przetestować, tworzysz nową gałąź i bezpiecznie sprawdzasz rezultat zmian wprowadzonych do projektu.

Operacje na gałęziach: rozgałęzianie i scalanie

Wizualizacja gałęzi w repozytorium

Aby podejrzeć historię zmian i pokazać gałęzie, wydaj polecenie w katalogu repozytorium:

Linia 1. git log minus minus graph minus minus full minus history minus minus all minus minus pretty.

Do przeglądania historii zmian na jednej wybranej gałęzi należy użyć polecenia:

Linia 1. git log otwórz nawias ostrokątny nazwa podkreślnik brancha zamknij nawias ostrokątny.

lub graficznego narzędzia do przeglądania repozytorium (np. gitk).

Tworzenie nowej gałęzi

Załóżmy, że nasze repozytorium wygląda tak jak na poniższym rysunku. Mamy kilka commitów oraz jedną gałąź master, pokazywaną przez wskaźnik HEAD:

Rwg9BQO1IHspS
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Utworzymy teraz nową gałąź i do niej właśnie przejdziemy (czyli będziemy z nią pracować). W tym celu wydajemy polecenia:

Linia 1. git branch develop kratka tworzy nową gałąź o nazwie develop. Linia 2. git checkout develop kratka zmiana gałęzi na develop.

Zamiast tych dwóch poleceń możesz także użyć jednego:

Linia 1. git checkout minus b develop.

Oto stan repozytorium:

RkBr2qGIzxtOY
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Wprowadź zmiany w repozytorium (np. dodaj plik), a następnie je zatwierdź:

Linia 1. git add otwórz nawias ostrokątny ścieżka podkreślnik do podkreślnik pliku zamknij nawias ostrokątny. Linia 2. git commit minus m cudzysłów opis wprowadzonych zmian cudzysłów.

Repozytorium wygląda następująco:

Rmxe9XwXtoKkq
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

W celu wyświetlenia istniejących gałęzi użyjemy polecenia:

Linia 1. git branch.

Powróćmy teraz do gałęzi master:

Linia 1. git checkout master.
RheiPm4V4NFcn
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Teraz pracujesz z gałęzią master. Wskaźnik HEAD ustawiony jest właśnie na nią.

Ponownie dodaj i zatwierdź zmiany w repozytorium. Graficzna reprezentacja wprowadzonych zmian wygląda następująco:

RpQ3QxgFMhRsd
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Scalanie gałęzi

Załóżmy, że zakończyliśmy pracę w gałęzi develop i chcemy ją scalić z gałęzią master (czyli włączyć wprowadzone poprawki do gałęzi głównej). Aby to zrobić, wydajemy następujące polecenia:

Linia 1. git checkout master kratka przejście do gałęzi master. Linia 2. git merge develop kratka scalenie gałęzi develop z gałęzią master.
R112GHeHbBBYQ
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

W wyniku scalania został utworzony nowy commit. Teraz gałąź master będzie zawierała zmiany, jakie zostały dokonane w gałęzi develop.

Pull request – co to takiego?

Pull request to prośba o zaakceptowanie zmian wprowadzonych do projektu. Mechanizm ten przydaje się podczas pracy grupowej. Pozwala on:

  • poinformować osoby zaangażowane w projekt o zmianach, jakich dokonano w wydzielonej gałęzi,

  • przedyskutować wprowadzone zmiany,

  • odrzucić lub włączyć zmiany do innej gałęzi projektu.

Pull request jest często stosowany podczas pracy przy dużych projektach typu open source. Tylko uprawnione osoby mogą dokonywać zmian w repozytorium. Jeśli pobraliśmy takie repozytorium na dysk komputera i wprowadziliśmy jakieś poprawki do kodu, a następnie chcemy, by zostały one włączone do oficjalnego projektu (i były dostępne dla wszystkich), musimy wystawić żądanie pull request.

Po tym następuje ReviewReviewReview.

RjT5QAG8LXw8D
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Opis projektu w języku Markdown

Przeglądając repozytoria w serwisie GitHub, można zauważyć, że towarzyszy im estetyczny, sformatowany opis. Może on zawierać spis treści, różnej wielkości nagłówki, odnośniki, przykłady użycia projektu czy wycinki z dokumentacji.

W serwisie GitHub dokument taki zapisany jest w pliku README.md, utworzonym z wykorzystaniem języka Markdown.

Markdown jest językiem znaczników, służącym do formatowania tekstu. Plik zapisany w formacie .md przekształcany jest do postaci w języku HTML.

Podstawowa składnia języka to:

  • Nagłówki: znacznik #

Linia 1. kratka H1. Linia 3. kratka kratka H2. Linia 5. kratka kratka kratka H3. Linia 7. kratka kratka kratka kratka H4.
  • Emfaza: znacznik * lub _

Linia 1. asterysk kursywa asterysk. Linia 3. asterysk asterysk pogrubienie asterysk asterysk. Linia 5. asterysk asterysk asterysk pogrubiona kursywa asterysk asterysk asterysk.
  • Listy: znacznik * lub + lub -

Linia 1. minus poz1. Linia 2. minus poz2. Linia 3. minus poz3.
  • Listy numerowane: 1, 2, 3 itd.

Linia 1. 1 kropka poz1. Linia 2. 2 kropka poz2.
  • Odnośniki: znacznik []()

Linia 1. To jest otwórz nawias kwadratowy Odnośnik zamknij nawias kwadratowy otwórz nawias okrągły http dwukropek prawy ukośnik prawy ukośnik epodreczniki kropka pl prawy ukośnik zamknij nawias okrągły kropka.
  • Spis treści – z użyciem odnośników do nagłówków: []()

Linia 1. otwórz nawias kwadratowy Informacje zamknij nawias kwadratowy otwórz nawias okrągły kratka informacje zamknij nawias okrągły.
  • Fragment kodu otwieramy: ```nazwa_języka i zamykamy: ```

Linia 1. ```python. Linia 2. print otwórz nawias okrągły cudzysłów Hello World wykrzyknik cudzysłów zamknij nawias okrągły. Linia 3. ```.

Plik .gitignore – co zawiera i do czego służy?

System kontroli wersji śledzi wszystkie zmiany w plikach znajdujących się w katalogu roboczym repozytorium. Często zdarza się jednak, że należy pominąć niektóre pliki lub całe katalogi.

System Git używa specjalnego pliku o nazwie .gitignore. Można w nim zapisać, które katalogi lub pliki nie powinny być monitorowane pod kątem wprowadzanych w nich zmian. Oznacza to, że jeżeli dany plik nie został nigdy „zacommitowany”, to nie będzie on przechowywany w repozytorium.

Jeśli nie widzisz w swoim repozytorium pliku .gitignore, możesz go utworzyć i zmieniać jego zawartość, korzystając z edytora tekstu.

Oto przykładowa zawartość pliku .gitignore:

Linia 1. prawy ukośnik Debug prawy ukośnik asterysk kropka o. Linia 2. data kropka db.

W przypadku tak przygotowanego pliku, .gitignore system Git nie będzie śledził zmian w plikach z rozszerzeniem .o znajdujących się w katalogu Debug oraz w pliku data.db.

Słownik

HEAD
HEAD

wskaźnik do zatwierdzonej wersji projektu (commitu), z którą obecnie pracujesz

review
review

przegląd i ocena implementacji danej funkcji przez członka zespołu; przegląd taki ma za zadanie wykrycie i poprawienie ewentualnych błędów; wpływa to pozytywnie na jakość tworzonego projektu

suma kontrolna
suma kontrolna

identyfikator służący do sprawdzenia poprawności danych (zbadania, czy są one wolne od błędów i nie zostały zmanipulowane); zazwyczaj jest to ciąg składający się z cyfr i liter; ciąg wyliczany jest według specjalnego algorytmu, od którego zależy m.in. długość sumy kontrolnej i stopień ochrony