GIT

kontrola wersji

10 listopada 2015 21:00
Krzysztof Kwaśniak

Co ten git? Co on?

Ten artykuł ma na celu pomóc Ci wkroczyć w świat gita like a baws. A przynajmniej mam taką nadzieje.

Co będzie potrzebne:

  • Twój ulubiony edytor tekstu,
  • git,
  • konto na repozytorum git
    • np. gitlab, github

Opcjonalnie możesz zainstalować narzędzie które pomoże Ci w "ogarnienciu" git'a:

Więc gdzie można zastosować git'a?

W zasadzie wszędzie gdzie chcesz trzymać rękę na pulsie nad zmianami w plikach. Oczywiście najlepsze będą pliki tekstowe: kod programu, dokumenty, strona www.

Pliki binarne z racji swojej natury nie nadają się do tego, tzn. nie będzie można porównać zmian co do znaku/linii. Będzie można jednak określić czy plik binarny różni się w stosunku do poprzedniej wersji / commita.

Jak zaczać?

Przejdz do folderu który chcesz by miał system kontroli wersji. A następnie wpisz lub skopiuj komendę.

git init

Git zainicjuje się, i będzie gotów do pracy.

Bierzemy się do roboty

Dodawanie pliku

Dodajmy nasz pierwszy plik, niech to będzie plik html o nazwie index.html.

<html>
    <body>
    </body>
</html>

Git jeszcze nie wie o tym, że powinien trzymać ręke na pulsie.

Jak sprawdzić status zmian śledzonych przez gita? Za pomocą git status!

Powinniśmy zobaczyć coś takiego

Untracked files:
(use "git add <file>..." to include in what will be committed)

        index.html

Git wie, że coś tam jest, ale nie wie jeszcze, że ma pilnować zmian. Możemy mu powiedzieć o tym za pomocą komendy git add plik / folder Czyli w naszym wypadku git add index.html lub też git add . (ta komenda doda zawartość folderu w którym się znajdujesz) Git rozpocznie śledzenie zmian, jednocześnie dodając ten plik do zmian które będą commitowane.

Ponownie po wpisaniu git status powinniśmy ujrzeć coś takiego:

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   index.html

Zatwierdzanie zmian

Zacommitujmy nasze zmiany komendą git commit -m 'dodanie 1 pliku' lub git commit

Co do samych nazw commitów - powinny być krótkie, zawierające informacje co się zmieniło / dodało / usuneło, ale jak wiadomo nie zawsze się da.

Pro tip: Co w takim wypadku? Kombinuj.

Teraz dodajmy sekcję head do naszego pliku html.

<html>
    <head>
    </head>
    <body>
    </body>
</html>

git status powinien zwrócić nam:

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

        modified:   index.html

Sprawdzanie zmian

O, ho! Git już zweszył zmiany, sprawdźmy co sie zmieniło, możemy to zrobić za pomocą komendy git diff

Zacommitujmy nasze zmiany, git commit -m 'dodanie sekcji head'

Niestety, nic się nie stanie, dlatego że git nie wie jakie zmiany ma zapisać. Ponownie dodajmy nasz plik git add index.html. Będziemy musieli robić to za każdym razem kiedy będziemy chcieli zapisać zmiany.

Branching

Teoria

No dobrze zróbmy cos bardziej zaawansowanego, zróbmy nowego brancha. Ale czym ten branch tak w ogóle jest?

Branch, z ang. gałąź, jest dla mnie trochę mylącą nazwą, bo gałęzie zazwyczaj nie wracają do pnia. Łopatologicznie - jest to po prostu inne miejsce do którego będą zapisywane nasze zmiany.

Teoria w praktyce

Po co tworzyć w ogóle te branche? Powodów jest kilka, najbardziej istotny to: porządek w zmianach / wersji. Branch może być dla jakichś zmian, np. dodanie nowej funkcjonalności, poprawienie błędu.

Nawet przy małych projektach branche są przydatne.

Zatem jak stworzyć nowego brancha? Poleceniem git branch <nazwa>, następnie trzeba zmienić brancha poleceniem git checkout <nazwa>

Czy można krócej? Oczywiście! git checkout -b <nazwa>, branch zostanie utworzony i zostaniemy przeniesieni od razu na niego.

Praktyka

Stwórzmy nowego brancha na nasze zmiany, git checkout -b uzupelnienie_head

I dodajmy <title>Tytuł</title> do naszego head.

<html>
    <head>
        <title>Tytuł</title>
    </head>
    <body>
    </body>
</html>

Teraz musimy to zacommitowac git commit -m 'uzupelnienie head', nie zapomnij dodać swojego pliku do commitu.

Mergowanie

Te zmiany będą tylko na naszym branchu, trzeba by je przenieść do naszego głównego brancha, którym jest master. Oczywiście nie bedziemy robić ctrl c, ctrl v. Wszystko zrobimy gitem. Żeby to zrobić musimy najpierw przenieść się do naszego głównego brancha, zrobimy to poleceniem git checkout master A następnie git merge uzupelnienie_head.

W praktyce gdy pracuje się w grupie, bardzo rzadko robi się merga w ten sposób, zazwyczaj robi to za nas serwer, po zatwierdzeniu przez inną osobę. Ma to na celu znalezienie błędu przez innych.

Praca z repozytorium zdalnym

Pushowanie

No dobrze, znasz już jako tako podstawy, teraz wyślemy nasze zmiany na serwer z repozytorium git. Utwórz swoje repozytorium (o ile jeszcze tego nie zrobiłeś) i skopiuj link do niego.

Następnie dodaj swoje repozytorium za pomocą git remote add origin <link>, a teraz wyślij te zmiany używając git push origin master. Gdy odświeżysz stronę zobaczysz swoje zmiany.

Teraz gdy chcesz by posłać swoje zmiany do swojego repozytorium zdalnego, zaraz po commicie wykonaj polecenie git push origin <branch> I to w zasadzie wszystko, pracowanie ze zdalnym repozytorium różni się od lokalnego tylko posłaniem tych zmian za pomocą git push.

Pullowanie i konflikty

Wiesz już jak wysłać swoje zmiany na serwer, teraz nauczysz się również je z tego serwera pobierać oraz rozwiązywać ewentualne konflikty. Utworz brancha o nazwie uzupelnienie_body, potem dodaj do naszego pliku index.html do sekcji body <p>Hello world</p>

<html>
    <head>
        <title>Tytuł</title>
    </head>
    <body>
        <p>Hello world</p>
    </body>
</html>

Zacommituj plik i poślij go na serwer poleceniem git push origin uzupelnienie_body i zmień brancha na master. Dodajmy jeszcze stopke strony na branchu dodanie_stopki.

<html>
    <head>
        <title>Tytuł</title>
    </head>
    <body>
        <div id="footer">Stopka</div>
    </body>
</html>

Zacommitujmy nasze zmiany i pushnijmy je na serwer. Przenieśmy się na brancha master. Zmergujmy naszego brancha z body za pomocą git merge uzupelnienie_body. Nie zapomnij wysłać tych zmian na serwer. Teraz trzeba zaktualizować zmiany z brancha master na branchu dodanie_stopki. Przenieśmy się na owego brancha i pobierzmy zmiany za pomocą git pull origin master Ojojoj, mamy konflikty, nie zdarzaja się one zawsze, tylko wtedy gdy mergowany / pobierany plik był edytowany w tym samym miejscu na 2 rożnych branchach. Niestety nie ma recepty na rozwiazanie konfliktów, trzeba je przejrzeć i zadecydować co powinno zostać a co powinno się usunąć. Po wykonaniu git diff powinniśmy zobaczyć mniej wiecej coś takiego.

diff --cc index.html
index 4df715d,6ce94e5..0000000
--- a/index.html
+++ b/index.html
@@@ -3,6 -3,6 +3,10 @@@
        <title>Tytuł</title>
    </head>
    <body>
++<<<<<<< HEAD
+       <div id="footer">Stopka</div>
++=======
+       <p>Hello world</p>
++>>>>>>> 775b1946cd913ec3eb86ea4bdc0563870737f7f3
    </body>
</html>

Tu sprawa jest prosta, trzeba przenieść stopke na dół tagu body i usunąć <<<<<<< HEAD, =======, >>>>>>> 775b1946cd913ec3eb86ea4bdc0563870737f7f3. Co te znaki oznaczają? Jak to czytać? Po między <<< HEAD a = jest to co my dodaliśmy w tym branchu, a pomiedzy = i >> jest to co było na branchu z którego pullowaliśmy / mergowaliśmy.

Wyedytujmy nasz plik by wyglądał tak.

<html>
    <head>
        <title>Tytuł</title>
    </head>
    <body>
        <p>Hello world</p>
        <div id="footer">Stopka</div>
    </body>
</html>

Dodajmy plik i zacommitujmy go, tym razem bez -m tylko git commit Git stworzy nam wiadomość sam, dobrym gestem jest odkomentować linijki mówiące o tym co było problemem. Tutaj nie ma to dużego znaczenia, ale gdy zmianny będą duże i konflików będzie dużo to wtedy pomoże to znaleść ewentualny problem, spowodowany błędnym rozwiązaniem konfliktów. Nie zapomnij wrzucić swoich zmian na serwer.

Teraz zmergujmy nasze zmiany do brancha master. Tym razem nie będzie konfliktów gdyż rozwiązaliśmy ten problem wcześniej. Tych zmian również nie zapomnij pushnać.

Podsumowując

Pushowanie zmian jest bardzo ważne, o ile pracujemy ze zdalnym repozytorium. Tłumacząc to łopatologicznie na przykładzie poczty. git add . określa co chcemy wrzucić do danej paczki git commit wypełnia dane adresata git push wysyła paczkę

Jeśli nie zrobimy git push wtedy paczka ciągle będzie u nas i nikt nie będzie o niej wiedział.

Comments