Podstawowe pojęcia związane z GITem

Opublikowane przez Tomasz Prasołek w dniu

Ten blog od początku był dla osób znających trochę system kontroli wersji GIT. Jednak postanowiłem również umieszczać tutaj wpisy związane z podstawami działania gita. W końcu nowi programiści wchodzący na rynek pracy muszą się nauczyć tego systemu kontroli wersji.

Dzisiejszy wpis będzie dotyczył właśnie podstawowych pojęć związanych z GITem.

System kontroli wersji

  • DVCS (Distribute Version Control System) – rozproszony system kontroli wersji. Oznacza to, że nie ma jednego głównego repozytorium, gdzie wszyscy się do niego łączą i commitują. W tym modelu każda osoba ma kopię całego repozytorium u siebie na dysku. GIT działa właśnie w takim modelu. Innym modelem jest CVC (Centralized Version Control), który jest używany np.: w SVN. Tam jest jedno główne centralne repozytiorium, z którego wszyscy pobierają i do któremy wszyscy przesyłają zmiany. Zaletą systemu rozproszonego jest możliwość pracy offline. W przypadku SVN jeśli nie mamy dostępu do internetu nie zrobimy commita i nawet nie sprawdzimy historii projektu, bo właśnie trzeba się połączyć z głównym serwerem.

Podstawowe pojęcia

  • HEAD – wskaźnik na lokalną gałąź, gdzie aktualnie się znajdujemy w repozytorium. Pokazuje na jakim commicie aktualnie jesteśmy. Zmienia się z każdym nowo powstałym commitem lub gdy przechodzimy na inny commit, poprzez np.: zmianę brancha.
HEAD
Animacja pokazująca jak zmienia się HEAD wraz z powstawaniem nowych commitów i zmiany brancha na inny.
  • Working area / working directory / katalog roboczy – miejsce gdzie robimy zmiany w naszym kodzie. W tym miejscu są widoczne wszystkie zmiany przez Nas popełnione, jeszcze nie zcommitowane i jeszcze nawet nie wrzucone do staging area / indexu.
  • Staging area / index – miejsce do którego wrzucamy kod (przy pomocy polecenia git add), który w przyszłości stanie się commitem. Polecenie git commit tworzy commit właśnie na podstawie wszystkich rzeczy znajdujących się w tym miejscu.
  • Commit – zapisana migawka plików naszego projektu. Commit zawiera wszystkie pliki projektu. W przypadku plików, które się nie zmieniły, git przechowuje tylko łącze do poprzedniego identycznego pliku, który jest już zapisany.
Rysunek ze strony: https://git-scm.com/book/en/v1/Getting-Started-Git-Basics
  • Każdy commit jest oznaczony unikalnym identyfikatorem SHA1. Commit tworzy się na podstawie kodu wrzuconego do staging area / indexu. Cała historia naszego projektu składa się z commitów. Każdy commit posiada swojego rodzica, którym jest inny commit (trochę dużo słowa commit w jednym akapicie 🙂 ). W commicie oprócz informacji o zmianach w kodzie są zapisywane jeszcze inne informacje takie jak: data, autor, opis (tzw. commit message).

Gałęzie / scalanie kodu i inne…

  • Branch – jest to oddzielna gałąź, na której znajduje się nasz kod. Na nowym branchu znajduje się oddzielny katalog roboczy, oddzielny staging area oraz całkiem inna historia projektu. Przy tworzeniu nowego repozytorium zawsze automatycznie jest tworzony branch o nazwie master. Przeważnie (zależy od ustaleń w zespole) przy naprawianiu bugów lub tworzeniu nowych funkcjonalności nowy kody robimy na oddzielnym branchu. W ten sposób nie mieszamy commitów nieskończonej funkcjonalności z kodem działającym na produkcji. Po skończonej pracy scalamy nasz branch z branchem głównym.
  • Merge – operacja połączenia kodu jednego brancha z drugim. Integracja 2 gałęzi w jedną.
git merge
Scalenie gałęzi feature do master.
  • Rebase – zmiana bazy dla wybranych commitów. Każdy commit ma jakieś rodzica (ten rodzic też jest commitem). Ta operacja zmieni tego rodzica. Przydatne polecenie gdy pracujemy na branchach, ale chcemy zachować prostą historię projektu.
git checkout feature >> git rebase master >> git checkout master >> git merge feature >> git branch -d feature
  • Repozytorium (tzw. repo) – to jest nasz katalog, w którym znajdują się wszystkie nasze pliki i wszystkie rzeczy związane z gitem – cała historia naszego projektu.
  • VIM – domyślny edytor tekstu instalowany razem z GITem. Jest on uruchamiany w paru przypadkach i osoby, które widzą go pierwszy raz nie umieją z niego wyjść 🙂 True story – na StackOverflow jest wątek How to exit the Vim editor?, która ma 1 875 550 wyświetleń :-). Jak działa VIM opisałem w poście: Edytor VIM – niezbędne skróty i polecenia przydatne do pracy z gitem
  • tip – najnowszy (ostatni) commit w danym branchu.
  • hunk – kawałek tekstu / kodu w modyfikowanym pliku.

Praca zdalna

  • remote – zdalne repozytorium, czyli po prostu kopia naszego lokalnego repozytorium umieszczona na jakimś serwerze.
  • origin – domyślna, skrócona nazwa zdalnego repozytorium. Pełna nazwa to po prostu URL do naszego zdalnego repozytorium.
  • upstream branch – zdalny branch połączony z naszym branchem lokalnym. Dzięki temu połączeniu przy pobieraniu lub wysyłaniu zmian GIT wie skąd pobrać dane i gdzie ma je wysłać.

Brakujące pojęcia?

Jeśli uważasz, że ominął opis jakiegoś pojęcia, a powinno się tutaj znajdować to daj znać w komentarzu i zaktualizuję wpis 🙂


Zdjęcie wykorzystane we wpisie pochodzi z portalu unsplash.com i zostało zrobione przez: unsplash-logoAaron Burden


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *