Praca z systemem kontroli wersji GIT

 

Słowem wstępu 

System kontroli wersji jest narzędziem pozwalającym na znacznie bardziej optymalną praca w projektach zespołowych.

Takim systemem jest GIT. Wasze projekty będą z kolei przechowywane w repozytorium GitHub (https://github.com).

Tutaj chciałbym podkreślić jedną rzecz: GIT to narzędzie, natomiast GitHub to serwis internetowy. 

Jak z tego korzystac w sposób prawidłowy i efektywny? Postaram się opisac to w tym tutorialu.

Na początek zacznijmy od podstaw i samej struktury GITa. 

Git jest programem, który instalujemy lokalnie na naszym komputerze i ma on za zadanie śledzić zmiany jakie wprowadzamy do plików w naszym projekcie.

Składa się on z trzech obszarów: 

  1. Katalog roboczy (Working tree) - to tutaj znajdować się będą pliki naszego projektu.
  2. Poczeklania (Staging Area) - ma za zadanie indeksować pliki naszego projektu.
  3. Lokalne repozytorium (Local Repository) - tutaj zapisywane będą rewizje naszego projektu, czyli zmiany w plikach. Ale pamiętaj, lokalne repozytorium to nie jest GitHub. Aby pliki z lokalnego repozytorium trafiły do GitHuba potrzebne będą pewne polecenia, o których w dalszej części tutoriala.

 

(rysunek)

 

 

Instalacja i konfiguracja GITa

Zanim zaczniemy używać GITa przy naszym projekcie, najpierw musimy go zainstalować w systemie. Jeśli pracujesz w Windowsie, musisz pobrać plik instalacyjny ze strony  https://git-scm.com/ . Instalacja jest stosunkowo prosta i polega właściwie na klikaniu next. W przypadku pracy w Linuxie, możliwe, że masz już zainstalowanego gita (np. w Ubuntu). Aby to sprawdzić wpisz w konsoli 

git --version

 Jeśli zobaczysz komunikat z numerem zainstalowanej wersji, to wszystko OK. A jeśli nie, to musisz zainstalować GITa w systemie:

sudo apt-get install git

To jeszcze nie wszystko. Zanim GIT zacznie działać potrzebna będzie jeszcze konfiguracja narzędzia.

Konfiguracja GITa może odbywać się na trzech poziomach:

  • systemowym - charakterystycznym dla danego komputera,
  • globalnym - charakterystycznym dla danego użytkownika,
  • lokalnym - charakterystycznym dla danego projektu.

Podstawowymi ustawieniami jest nazwa użytkownika i jego e-mail, które służą identyfikacji autora zmian wprowadzonych do projektu.

Aby wykonać konfigurację na poziomie lokalnym musimy w konsoli wpisać nastepujące polecienia:

git config --local user.name "Nazwa użytkownika"

git config --local user.email "nasz@email.com"

 

Konfiguracja na poziomie globalnym będzie wykonana poleceniami:

git config --global user.name "Nazwa użytkownika"

git config --global user.email "nasz@email.com"

 

Dodatkowo w systemie Windows można skonfigurować automatyczne zapisywanie hasła do repozytorium zdalnego (kiedy już zaczniemy przesyłać pliki do GitHuba):

git config --global credential.helper wincred

Konfigurację wykonujemy jednorazowo i nie ma konieczności powtarzania jej przy każdym nowym projekcie. 

Aby sprawdzić ustawienia możemy wydać polecienie: 

git config --global --list

Teraz czas odpalić GITa.

 

Rozpoczynamy pracę

A zatem uruchamiamy gita. Najpierw wchodzimy do folderu z naszym projektem. Jeśli pracujesz w Windowsie możesz wywołać menu kontekstowe w folderze (prawy klik myszą) i wybrać Git bash here

Otworzy się okno konsoli. Teraz zainicjujemy pracę GITa poleceniem:

git init

Od tej pory GIT będzie sprawował opiekę nad folderem z projektem. Nasz folder z projektem to teraz przestrzeń robocza (Working tree) dla GITa. 

Jeśli w folderze sa już jakies pliki (powiedzmy, plik1.txt, plik2.txt, plik3.txt), to dodamy je teraz do poczeklani:

git add plik1.txt plik2.txt plik3.txt

 Możemy wrzucić wszystkie pliki hurtowo, bez konieczności ich wypisywania (przy 100 plików kinomu nie bedzie się chciało wypisywać nazw wszystkich plików)

git add .

W powyższym poleceniu, kropka reprezentuje wszystkie pliki w folderze.

Tutaj ważna uwaga. GIT nie widzi folderów pustych w przestrzeni roboczej, ale foldery z zawartością sa już widoczne dla GITa. Właśnie zaindeksowaliśmy pliki w poczeklani.

Teraz pora przenieść je z poczekalni do lokalnego repozytorium:

git commit -m "komentarz"

Właśnie zapisaliśmy pierwszą rewizję projektu, czyli zrobiliśmy commita. Zauważ, że nasz commit musi byc opatrzony komentarzem i to nie byle jakim. Oto dwa podstawowe kryteria tworzenia komentarza:

  • musi mieć nie więcej niż 50 znaków,
  • musi być napisany po angielsku w czasie Present Simple, (żaden Past Perfect Simple, lub Future Past Perfect Continous). 

Zazwyczaj jako pierwszy komentarz w projekcie możemy wpisać "Initial commit".

Te komentarze pozwolą później odnaleźć właściwą rewizję i przywrócić pliki do poprzedniego stanu (w razie konieczności przywołania pliku w poprzedniej wersji). Ponadto, nasi wpsółpracownicy też będą mieli łatwiej widząc czego dotyczy dana rewizja.

Tutaj jeszcze jedna ważna uwaga: staraj się tworzyć commity za każdym razem gdy stworzysz jedną nową funkcjonalność, lub naniesiesz jedną poprawkę. Ale niegdy nie rób commita, który będzie obejmował kilka różnych funkcjonalności lub poprawek. Gdybyś dodał do pliku z kodem 10 nowych metod i jedna z nich okazałaby się wadliwa, to musiałbyś wycofać zmiany (przywrócić poprzednią wersję pliku) usuwając tym samym 9 prawidłowo działających metod. 

Aktualny stan wszystkich przestrzenie GITa możesz sprawdzić poleceniem:

git status

 

Informacje na temat rewizji

Kazda rewizja, jaką stworzymy w GIT będzie opatrzona uniklanym numerem w postaci kodu SHA. Informacje o ostatniej wykonanej rewizji mogą być wyświetlone poleceniem:

git show

Możemy również sprawdzić informacje o dowolnej rewizji na podstawie jej kodu SHA:

git show 25b2a9

Numer rewizji jest dość długi (np. 8b0ef09796e3d071a9ba5eac66a133cee44e6981), ale ne ma konieczności wpisywania całego kodu SHA, tylko pierwsze 5 znaków (co najmniej). 

 

 

C.D.N......