git system kontroli wersji

System kontroli wersji GIT

GIT (System Kontroli Wersji) to oprogramowanie służące do rejestrowania zmian zachodzących w kodzie aplikacji związanych z rozbudową lub aktualizacją funkcjonalności. Git pozwala śledzić historię tych zmian a więc tworzyć wersje projektu. W razie awarii pozwala przywrócić poprzedni stan. Używany jest głównie jako narzędzie pozwalające pracować grupie osób nad jednym, wspólnym projektem.

Tak to wygląda w telegraficznym skrócie 🙂

1. INSTALACJA GITa

Gita można pobrać z oficjalnej strony git-scm.com/downloads.
Do wyboru mamy wersje dla systemów: MAC OS X, Windows oraz Linux/Unix.
Oprócz Gita musimy zainstalować serwer lokalny WWW. Ja polecam XAMPP, który jest wstępnie skonfigurowany i od razu można na nim działać 🙂

Jeżeli nasze środowisko pracy jest już gotowe to możemy rozpocząć pracę z GITem.

2. TWORZENIE REPOZYTORIUM

Na początek utworzymy nowe repozytorium. W tym celu przejdź na serwerze lokalnym do katalogu /htdocs i utwórz podkatalog o nazwie np: Projekt. Może to być katalog ze stroną WWW itp.

Z wiersza poleceń wykonaj komendę:

git init


Polecenie git init utworzyło katalog .git ze szkieletem naszego repozytorium oraz bazą danych projektu. Nie musimy się w to na razie zagłębiać 🙂

3. KONFIGURACJA NAZWY UŻYTKOWNIKA

Opcjonalnie możesz skonfigurować swój profil użytkownika. Profil ten zostanie przypisany do operacji, które będziesz wykonywał na repozytorium.

 

4. TRZY STANY PLIKÓW

Pliki, na których pracujesz na lokalnym serwerze, mogą posiadać trzy stany: zmodyfikowany, śledzony, zatwierdzony. Przepływ tej pracy odbywa się w sekcjach:

  • KATALOG ROBOCZY (working directory) – to katalog, w którym jest nasz projekt (lub jakaś wersja projektu), może to być strona WWW, aplikacja na Androida itd. W tym katalogu tworzysz nowe pliki lub je edytujesz (w naszym przykładzie jest to katalog /Projekt),
  • PRZECHOWALNIA (stage) – do której trafiają pliki z katalogu roboczego, są one śledzone przez Gita i czekają na zatwierdzenie (commit),

    Powyższe polecenie dodaje plik/i do śledzenia. Można wskazać katalog lub pojedyncze pliki. Aby dodać wszystkie nowe i zmodyfikowane pliki wykonaj polecenie:

  • REPOZYTORIUM GIT (HEAD) – zatwierdzone pliki są zapisywane w bazie .git i z tego miejsca można je dopiero przesłać do zdalnego repozytorium, (ale o tym w następnym punkcie).

    Polecenie commit zatwierdza zmiany. W miejsce message wprowadzamy komentarz.

Dla przykładu, utwórz plik hello.txt w katalogu /Projekt i wprowadź do niego zawartość np: Hello World! Zapisz zmiany i dodaj plik do przechowalni:

Zatwierdź zmiany:

Plik hello.txt jest teraz w bazie .git.

5. ZDALNE REPOZYTORIUM – GITHUB

Zdalne repozytorium to po prostu miejsce na zewnętrznym serwerze („w chmurze”) np: GitHub, BitBucket, w którym możesz umieścić swoje lokalne repozytorium i pochwalić się jakimś ciekawym rozwiązaniem, programem, modułem, biblioteką itd. W większości firmach, głównym przeznaczeniem jest wspólna przestrzeń dla programistów, którzy mogą pracować nad tym samym zadaniem, nie wchodząc sobie w drogę. Każdy członek zespołu może przesłać (git push) swój kod i zaproponować zmiany na swoim oddzielnym odgałęzieniu (git branch). Po akceptacji gałęzie są scalane (git merge) z główną gałęzią master. W ten sposób powstaje gotowa (aktualna) wersja projektu, którą można pobrać / sklonować (git clone) na swój lokalny komputer do katalogu roboczego i pracować nad kolejnymi funkcjonalnościami.
Praca z wieloma gałęziami będzie opisana w dalszej części tego artykułu.

Do dalszej nauki wykorzystamy GitHub. Załóż w serwisie darmowe konto a następnie kliknij w prawym górnym rogu znak „+” i wybierz: „New repository” – https://github.com/new. Wprowadź nazwę (np: test) i kliknij przycisk „Create repository” :

github new repository


Zdalne repozytorium o nazwie test zostało utworzone. Jak na razie jest puste, ale zaraz coś dodamy 😉

6. WYSYŁANIE ZMIAN DO ZDALNEGO REPOZYTORIUM

Aby wysłać lokalne repozytorium (htdocs/Projekt) do GitHuba wykonaj instrukcje:

Pierwsze polecenie łączy lokalne repozytorium ze zdalnym serwerem. Nazwę <username> zmień na nazwę swojego konta. Drugie polecenie wysyła lokalne repozytorium do głównej gałęzi master, na serwerze GitHub. Oczywiście, gałąź master, możesz zastąpić nazwą innej gałęzi, do której wysyłasz zmiany. Na razie operować będziemy tylko na głównej gałęzi.

Kiedy przejdziesz do strony https://github.com/<username>/test to zobaczysz plik hello.txt z lokalnego repozytorium. Czyli jest git 🙂


Zaktualizuj w katalogu roboczym zawartość pliku hello.txt i zapisz zmiany.


Wyślij zmiany na serwer do gałęzi master:

Zmiany oczywiście pojawiły się na serwerze zdalnym 🙂 ale możesz upewnić się klikając w nazwę pliku. Po jego otwarciu zobaczysz aktualną zawartość:


7. AKTUALIZACJA I SCALANIE LOKALNEGO REPOZYTORIUM

No dobra, ale co w sytuacji kiedy oryginalne pliki na serwerze zostaną zmienione przez inną osobę lub dodano coś nowego, a Ty o tym nie wiesz 🙂 ?
Oczywiście, że Git ma na to sposób. Wystarczy wykonać proste polecenie:

lub ze wskazaniem na główną gałąź:

Polecenie pobiera najnowszą wersję repozytorium i scala je z Twoimi plikami na lokalnej maszynie. Tak więc przed rozpoczęciem każdego zadania, można profilaktycznie wykonać tą komendę i spać spokojnie 🙂

W celach testowych edytuj plik hello.txt bezpośrednio w serwisie GitHub (jak na obrazku poniżej); wprowadź jakieś zmiany a na koniec kliknij przycisk „Commit changes„. W konsoli wiersza poleceń wydaj polecenie git pull. Otwórz plik hello.txt z lokalnego katalogu roboczego i upewnij się, że zawartość została zaktualizowana.


8. COFANIE ZMIAN W KATALOGU ROBOCZYM

Może zdarzyć się, że z jakiegoś powodu będziesz chciał cofnąć zmiany w katalogu roboczym i przywrócić ostatnią działającą wersję pliku/ów z HEAD (.git), wtedy użyj polecenia:

Przykład:

Cofnięcie zmian we wszystkich zmienionych plikach:

Aby powrócić do wybranego commita wykonaj polecenie:

Przykład:

Oczywiście jest tego więcej, ale to już temat na kolejny artykuł 🙂

9. KLONOWANIE ZDALNEGO REPOZYTORIUM

Git pozwala w prosty sposób utworzyć kopię roboczą repozytorium. W tym celu utwórz katalog np: Test_Clone (w lokalizacji /htdocs/Test_Clone). W konsoli wiersza poleceń przejdź do tego katalogu i wykonaj polecenie:

W serwisie GitHub mamy do tego specjalny przycisk „Clone or Download” i jak widać na poniższym obrazku można też pobrać spakowane archiwum ZIP.

pobieranie repozytorium


10. GAŁĘZIE

Gałęzie pozwalają na rozwijanie funkcjonalności aplikacji bez ingerencji w przepływ pracy innych osób w zespole. Każdy może pracować na swojej niezależnej gałęzi, a po akceptacji zmian podgałąź można scalić z główną gałęzią – master. Gałąź master już znasz, bo dotychczas pracowaliśmy tylko na niej 🙂 Jest to domyślna gałąź repozytorium.

Aby utworzyć nową gałąź użyj polecenia:

Przykład:

Aby sprawdzić, która gałąź jest aktywna wykonaj polecenie:

git branch


Jak widać, aktywną gałęzią jest teraz feature_test.

Aby z powrotem przełączyć się na gałąź master wykonaj polecenie:

Aby wysłać nową gałąź do zdalnego repozytorium wykonaj:

 

11. SCALANIE GAŁĘZI

Przykład:

  • aktualizujemy lokalną wersję pliku hello.txt ze zdalnego serwera, no chyba, że sam pracujesz nad zawartością tego pliku i wiesz, że od ostatniego commita nic się nie zmieniło, to możesz pominąć ten krok 🙂

  • tworzymy gałąź:

Automatycznie zostaniesz przełączony na nową gałąź.

  • jeśli zaktualizowałeś plik hello.txt, dodajemy zmiany do przechowalni:

  • zatwierdzamy zmiany:

  • wysyłamy zmiany na zdalny serwer (do GitHub):

Na GitHubie zmiany będą widoczne po wejściu na stronę:

github branches

Kliknij odnośnik 2 branches lub wybierz z listy swoją gałąź:

github branches

i przejdź do widoku pliku klikając w jego nazwę. Jak widać plik jest zaktualizowany, oczywiście tylko w Twoim branchu 🙂

git branches

A teraz scalimy zmiany z gałęzią główną master. Wpierw musimy wykonać pull request, który pozwala porównywać zmiany w pliku/ach i wyświetla ewentualne konflikty (błędy) przed scalaniem.

Tak więc, kliknij przycisk Compare & pull request:

pull request

Wprowadź opcjonalnie komentarz i zatwierdź operację klikając przycisk Create pull request:

githun create pull request

Jeśli nie pojawiły się żadne konflikty (o czym zresztą zostaniesz poinformowany) kliknij przycisk Merge pull request:

github merge pull request

Po zatwierdzeniu wyświetli się informacja o poprawnym złączeniu gałęzi, jak widać z obrazka branche możesz również usuwać 😉

merge branche

Po przełączeniu się na gałąź master zobaczysz, że zmiany, które zaproponowałeś w gałęzi feature/hello są teraz również w oryginalnym pliku hello.txt.

I to tyle, jeśli chodzi o gałęzie. Oczywiście, temat ten jest dużo bardziej złożony, np. pomijam forkowanie i rozproszony przepływ pracy, na które poświęcę osobny artykuł 😉

Więcej informacji i przydatnych poleceń znajdziesz w dokumentacji git-scm.com/doc lub używając komendy:

 


Leave a Comment

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