Git #1: pierwsze kroki

W artykule dotyczącym fixur pokrótce wyjaśniłem ich działanie. Teraz chciałem przybliżyć ich przydatność w praktyce, rozbudowując wątek z czwartej części serii o Raspberry Pi w testach embedded.

Git

Git #1: pierwsze kroki


Git jest najpopularniejszy system kontroli wersji. Nie bez powodu zdobył rzeszę zwolenników. Po pierwsze jest darmowy (wszyscy lubimy darmowe, dobrze działające i przydatne narzędzia). Większość operacji wykonujemy lokalnie, co znacznie ułatwia pracę zdalną i nie blokuje projektu w przypadkach problemów z połączeniem do serwera. Korzystamy z tak zwanych komitów (commits). Są w nich zapisane kolejne stany projektu (stan plików w danym momencie, lub ich referencje, jeżeli nie były zmieniane od poprzedniego komitu). Możemy do nich wrócić lub przywrócić w każdym momencie projektu (także lokalnie), a także sprawdzić jaka część kodu została dodana przez którego członka zespołu. Z istniejącego projektu możemy tworzyć rozgałęzienia (branches). Możemy równolegle wprowadzać na nich zmiany i po zakończonej pracy dodawać je do głównego repozytorium w danej chwili. Może na tym skończę wychwalanie Git’a i przejdę do części praktycznej.

Instalacja

Na systemie linux (np. Ubuntu czy Raspbian), można użyć komendy apt-get install git

sudo apt-get install git

Dla systemu Windows pobieramy git ze strony:

I instalujemy krok po kroku według wytycznych w instalatorze. Po instalacji i ponownym uruchomieniu systemu Windows, gdy w dowolnym folderze naciśniemy prawy przycisk myszy w menu zobaczymy „Git Bash Here”. Gdy wybierzemy tę opcję naszym oczom ukaże się konsola rodem z linuxa (na dowód jej „linuxowości” wpisz komendę ls, a zobaczysz informację o zawartości folderu, w którym się znajdujesz). Tak przygotowani możemy używać tych samych komend dla Windowsa i Linuxa.

Podstawowe komendy

Stwórzmy folder, w którym zainicjalizujemy repozytorium za pomocą git init

pi@raspberrypi:~ $ mkdir test
pi@raspberrypi:~ $ cd test
pi@raspberrypi:~/test $ git init
Initialized empty Git repository in /home/pi/test/.git/
pi@raspberrypi:~/test $

Aby dowiedzieć się, jaki jest status naszych zmian, czy gdzie się znajdujemy (na jakiej gałęzi) wystarczy, że użyjemy komendy git status

pi@raspberrypi:~/test $ git status
On branch master
 
Initial commit
 
nothing to commit (create/copy files and use "git add" to track)
pi@raspberrypi:~/test $

Wychodzi na to, że jeszcze nic nie posiadamy na naszym branchu master. Stworzył się przy inicjalizacji i jest naszą główną gałęzią. Kolejnym krokiem będzie dodanie plików. A więc stwórzmy plik „file_one.py” i dodajmy go do repozytorium komendą git add

pi@raspberrypi:~/test $ touch file_one.py
pi@raspberrypi:~/test $ ls
file_one.py
pi@raspberrypi:~/test $ git add file_one.py
pi@raspberrypi:~/test $ git status
On branch master
 
Initial commit
 
Changes to be committed:
  (use "git rm --cached ..." to unstage)
 
	new file:   file_one.py
 
pi@raspberrypi:~/test $

Po dodaniu pliku użyłem komendy git status, aby pokazać jak, po dodaniu nowego pliku, Git go rozpoznaje. Aby go zapisać (na razie lokalnie), użyjemy komendy git commit -m „Tytuł naszego komita”. Tytuły komitów powinny opisywać klarownie i zwięźle, co dany zapis zawiera – tak aby wszyscy pracujący nad projektem w prosty sposób mogli rozszyfrować, co znajduje się w dodanych zmianach.

pi@raspberrypi:~/test $ git commit -m "First file (file_one.py) was added"
 
*** Please tell me who you are.
 
Run
 
  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"
 
to set your account's default identity.
Omit --global to set the identity only in this repository.
 
fatal: empty ident name (for <(null)>) not allowed
pi@raspberrypi:~/test $

Operacja jak widać, skończyła się niepowodzeniem, gdyż jak widzimy nie dokończyliśmy konfiguracji naszego Git’a. System wymaga od nas podania maila i imienia, jest to potrzebne do identyfikacji osoby, która wprowadza zmiany. Zróbmy to, aby w przyszłości każdy mógł odnaleźć informacje o twórcy „najlepszych” 😉 części kodu w naszych projektach.

pi@raspberrypi:~/test $ git config --global user.email "szymon@qabrio.pl"
pi@raspberrypi:~/test $ git config --global user.name "Szymon"

Tak przygotowani możemy komitować nasze zmiany.

pi@raspberrypi:~/test $ git commit -m "First file (file_one.py) was added"
[master (root-commit) 68ce2aa] First file (file_one.py) was added
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file_one.py
pi@raspberrypi:~/test $ git status
On branch master
nothing to commit, working tree clean
pi@raspberrypi:~/test $

Jak widzimy, zmiany zostały zapisane. Aby zobaczyć historię wprowadzonych zmian, użyj komendy git log

pi@raspberrypi:~/test $ git log
commit 68ce2aa9e3f62e2f7a89bee45265e0cadb9edb35
Author: Szymon @qabrio.pl>
Date:   Tue Jul 23 22:29:18 2019 +0100
 
    First file (file_one.py) was added
pi@raspberrypi:~/test $

Na deser tego artykułu plik .gitignor. Dodane do niego ścieżki i pliki nie będą wciągane do komitów ani widziane w statusie repozytorium. Niesamowicie przydatne np. przy tworzeniu logów których (zazwyczaj) nie chcemy umieszczać w repozytorium. Stwórzmy więc pliki .gitignor i test_file.log.

pi@raspberrypi:~/test $ touch test_file.log
pi@raspberrypi:~/test $ touch .gitignore
pi@raspberrypi:~/test $ git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)
 
	.gitignore
	test_file.log
 
nothing added to commit but untracked files present (use "git add" to track)

Za pomocą pliku .gitignor, „zignorujemy”  test_file.log. Użyj edytora Nano (nano .gitignore) i dodaj linijkę test_file.log, po czym zapisz plik. Po tej operacji wywołaj znowu git status

pi@raspberrypi:~/test $ git status
 
On branch master
 
Untracked files:
 
  (use "git add ..." to include in what will be committed)
 
.gitignore
 
nothing added to commit but untracked files present (use "git add" to track)

Plik test_file.log znika z proponowanych do commitowania plików.

Tak przygotowani możemy wyjść z cienia lokalnych zmian na świat. Ale o tym w następnej części.

close

Newsletter