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ę:
|
1 |
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.
|
1 2 |
git config --global user.name "John Doe" git config --global user.email johndoe@example.com |
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),
1git add <path/to/file>
Powyższe polecenie dodaje plik/i do śledzenia. Można wskazać katalog lub pojedyncze pliki. Aby dodać wszystkie nowe i zmodyfikowane pliki wykonaj polecenie:
1git add . - 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).
1git commit -m "message"
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:
|
1 |
git add hello.txt |
Zatwierdź zmiany:
|
1 |
git commit -m "dodanie pliku z powitaniem" |
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” :
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:
|
1 2 |
git remote add origin https://github.com/<username>/test.git git push -u origin master |
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:
|
1 2 3 |
git add hello.txt git commit -m "zaktualizowanie zawartości pliku" git push -u origin 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:
|
1 |
git pull |
lub ze wskazaniem na główną gałąź:
|
1 |
git pull origin master |
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:
|
1 |
git checkout -- <path/to/file> |
Przykład:
|
1 |
git checkout -- hello.txt |
Cofnięcie zmian we wszystkich zmienionych plikach:
|
1 |
git checkout . |
Aby powrócić do wybranego commita wykonaj polecenie:
|
1 |
git revert --no-edit HEAD~<numer_commita>… |
Przykład:
|
1 |
git revert --no-edit HEAD~5… |
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:
|
1 |
git clone https://github.com/<username>/test.git |
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.
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:
|
1 |
git checkout -b <nazwa_gałęzi> |
Przykład:
|
1 |
git checkout -b feature_test |
Aby sprawdzić, która gałąź jest aktywna wykonaj polecenie:
|
1 |
git branch |
Jak widać, aktywną gałęzią jest teraz feature_test.
Aby z powrotem przełączyć się na gałąź master wykonaj polecenie:
|
1 |
git checkout master |
Aby wysłać nową gałąź do zdalnego repozytorium wykonaj:
|
1 |
git push origin feature_test |
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 🙂
|
1 |
git pull origin master |
- tworzymy gałąź:
|
1 |
git checkout -b feature/hello |
Automatycznie zostaniesz przełączony na nową gałąź.
- jeśli zaktualizowałeś plik hello.txt, dodajemy zmiany do przechowalni:
|
1 |
git add hello.txt |
- zatwierdzamy zmiany:
|
1 |
git commit -m "aktualizacja powitan" |
- wysyłamy zmiany na zdalny serwer (do GitHub):
|
1 |
git push origin feature/hello |
Na GitHubie zmiany będą widoczne po wejściu na stronę:
Kliknij odnośnik 2 branches lub wybierz z listy swoją gałąź:
i przejdź do widoku pliku klikając w jego nazwę. Jak widać plik jest zaktualizowany, oczywiście tylko w Twoim branchu 🙂
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:
Wprowadź opcjonalnie komentarz i zatwierdź operację klikając przycisk Create pull request:
Jeśli nie pojawiły się żadne konflikty (o czym zresztą zostaniesz poinformowany) kliknij przycisk 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ć 😉
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:
|
1 |
git log --help |