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 $\text{C1}$, $\text{C2}$, $\dots$, $\text{Cn}$.

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

R1NEAZwDgXIMg

Ilustracja przedstawia trzy okręgi z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg zielony z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Pod Okręgiem C3 znajdują się podpisy: master oraz head.

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

• $\text{C1}$ jest rodzicem $\text{C2}$,

• $\text{C2}$ jest rodzicem $\text{C3}$ i dzieckiem $\text{C1}$,

• $\text{C3}$ jest dzieckiem $\text{C2}$.

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

Ilustracja przedstawia cztery okręgi z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Czwarty okrąg zielony z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Pod Okręgiem C4 znajdują się podpisy: master oraz head.

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 $\text{C4}$ 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

Ilustracja przedstawia cztery okręgi z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Czwarty okrąg zielony z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Pod Okręgiem C4 znajdują się podpisy: master, head oraz develop.

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

RR562GFFDA4xn

Ilustracja przedstawia sześć okręgów z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Czwarty okrąg niebieski z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Piąty okrąg niebieski z wpisaną wartością: C5, wychodzi od niego strzałka wskazująca na niebieski okrąg C4. Pod Okręgiem C5 znajduje się podpis: Develop.
Szósty okrąg zielony z wpisaną wartością: C6, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C6 znajdują się podpisy: master oraz head.

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:

git log --graph --full-history --all --pretty

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

git log <nazwa_brancha>

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

Ilustracja przedstawia cztery okręgi z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Czwarty okrąg zielony z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Pod Okręgiem C4 znajdują się podpisy: master oraz head.

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

git branch develop 	# tworzy nową gałąź o nazwie develop
git checkout develop 	# zmiana gałęzi na develop

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

git checkout -b develop

Oto stan repozytorium:

RkBr2qGIzxtOY

Ilustracja przedstawia cztery okręgi z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
Czwarty okrąg zielony z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Pod Okręgiem C4 znajdują się podpisy: master, head oraz develop.

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

git add <ścieżka_do_pliku>
git commit -m "opis wprowadzonych zmian"

Repozytorium wygląda następująco:

Rmxe9XwXtoKkq

Ilustracja przedstawia pięć okręgów z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
czwarty okrąg niebieski z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3. Pod okręgiem C4 znajduje się podpis: master.
Piąty okrąg zielony z wpisaną wartością: C5, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C5 znajdują się podpisy: head oraz develop.

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

git branch

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

git checkout master

RheiPm4V4NFcn

Ilustracja przedstawia pięć okręgów z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
czwarty okrąg niebieski z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3. Pod okręgiem C4 znajduje się podpis: master oraz head.
Piąty okrąg zielony z wpisaną wartością: C5, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C5 znajdują się podpisy: develop.

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

Ilustracja przedstawia sześć okręgów z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
czwarty okrąg niebieski z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Piąty okrąg niebieski z wpisaną wartością: C5, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C5 znajdują się podpisy: develop.
Szósty okrąg zielony z wpisaną wartością: C6, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C6 znajdują się podpisy: master oraz head.

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:

git checkout master 	# przejście do gałęzi master
git merge develop 	# scalenie gałęzi develop z gałęzią master

R112GHeHbBBYQ

Ilustracja przedstawia siedem okręgów z podpisami.
Pierwszy niebieski okrąg z wpisem: C1, podpisana jako: first commit. .
Drugi niebieski z wpisem: C2, wychodzi od niego strzałka na okrąg C1.
Trzeci okrąg niebieski z wpisaną wartością: C3, wychodzi od niego strzałka wskazująca na niebieski okrąg C2.
czwarty okrąg niebieski z wpisaną wartością: C4, wychodzi od niego strzałka wskazująca na niebieski okrąg C3.
Piąty okrąg niebieski z wpisaną wartością: C5, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Pod Okręgiem C5 znajdują się podpisy: develop.
Szósty okrąg zielony z wpisaną wartością: C6, wychodzi od niego strzałka wskazująca na niebieski okrąg C4.
Siódmy okrąg niebieski posiada wpis: C7, wychodzą od niego strzałki do okręgów C6 i C5.
Pod okręgiem C7 znajdują się opisy: master oraz head.

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

Ilustracja przedstawia prostą z dwoma punktami.
Pierwszy punkt znajduje się na początku prostej.
Wychodzi od niego strzałka wskazująca na blok z wpisem: Commits. Od niego następnie wychodzi strzałka do bloku z napisem: Pull request., od tego bloku wychodzi strzałka do następnego z wpisem: Review..
Od ostatniego bloku wchodzi strzałka wskazująca na punkt znajdujący się na koniec prostej powyżej.

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 #

# H1

## H2

### H3

#### H4

• Emfaza: znacznik * lub _

*kursywa*

**pogrubienie**

***pogrubiona kursywa***

• Listy: znacznik * lub + lub -

- poz1
- poz2
- poz3

• Listy numerowane: 1, 2, 3 itd.

1. poz1
2. poz2

• Odnośniki: znacznik [] i ()

To jest [Odnośnik](http://epodreczniki.pl/).

• Spis treści – z użyciem odnośników do nagłówków: [] i ()

[Informacje](#informacje)

• Fragment kodu otwieramy: ```nazwa_języka i zamykamy: ```

```python
print("Hello World!")
```

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:

/Debug/*.o
data.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