My git workflow

02 February 2011

Postanowiłem spisać etapy pracy z repozytorium Gita z zachowaniem "liniowej historii" projektu. Póki co używam Gita na wzór scentralizowanych systemów wersjonowania kodu. To dlatego, że nie mogę ogarnąć rozumem tego całego mergowania. To jest workflow, z którego korzystałem zapisując kod do repozytorium założonym w serwisie unfuddle.com. Serwis ten umożliwia prowadzenie za darmo prywatnych projektów (repozytorium Git/Subversion, tickety, dashboard, max 2 osoby w projekcie - w darmowej wersji). Zakładam, że:

  • para kluczy SSH została wygenerowana lokalnie i klucz publiczny zapisany na serwerze,
  • repozytorium zostało juz sklonowane i folder .git znajduje się w folderze src projektu.

Oto schemat działania w moim przypadku. Uruchamiam komputer a potem w terminalu:

  1. Przechodzę do folderu src mojego projektu: cd /mnt/laptop/projects/java/Projekt/src
  2. Sychronizuję lokalne repo z tym na serwerze: git pull --rebase origin master
  3. Modyfikuję pliki, kompiluję, testuję, modyfikuję itd... W momencie gdy wykonałem jedną niekoniecznie dużą zmianę w programie, dokonuje commita do lokalnego repozytorium: git commit -a Dzięki parametrowi a wszystkie zmodyfikowane pliki zostaną dodane do indexu a następnie zacommitowane. Nie muszę więc ręcznie dodawać plików do indexu za pomocą polecenia: git add ZmodyfikowanyPlik.java Jednak w przypadku gdy stworzyłem w projekcie nowy plik, przed zrobieniem commita muszę użyć na nim polecenia: git add NowyPlik.java
  4. Po wykonaniu commita zaczynam pracę nad kolejną zmianą. Dokonuję w sumie kilku commitów.
  5. Bezpośrednio po wykonaniu ostatniego commita, zanim upublicznię swoje zmiany na serwerze, sprawdzam czy w czasie gdy ja pracowałem na lokalnej kopii repo, nie nastąpiły zmiany w repo serwerowym: git pull --rebase origin master To polecenie powoduje, że wszelkie zmiany, które zaszły w serwerowym repo zostaną wgrane do mojego lokalnego repo i nastąpi próba ponownego dodania moich (jeszcze nieopublikowanych) commitów do najnowszej wersji lokalnego repo. Jeśli moje commity są w konflikcie z nową wersją repo Git mnie o tym powiadomi i moim zadaniem będzie je rozwiązać lub opuścić skonfliktowane commity.
  6. Teraz jestem w stanie opublikować najnowsze zmiany na serwerze: git push origin master
  7. Wyłączam komputer i idę spać.