Obejrzałem dziś prezentację pt: Git — krok po kroku Michała Lewandowskiego w ramach Jinkubatora .
Zachęciło mnie to do napisania posta, aby przelać “na papier” słowa wypowiedziane.
Michał podczas prezentacji, przedstawił jak działa Git, w jaki sposób radzi on sobie z tworzeniem rewizji, branchy czy tagów. Na początku prezentacji Michał zareklamował narzędzie tig z którego miał często korzystać podczas weryfikacji stanu repozytorium, jednak chyba ze względu na stres korzystał z sourceTree 😄
Bardzo mnie zaciekawiło to narzędzie (tig oczywiście, nie sourceTree), zrobiłem więc szybki research i od razu postanowiłem, że się z nim zaprzyjaźnię.
Tig
Kiedyś, gdy w ferworze rozglądałem się nad jakimiś narzędziami z GUI do zarządzania repozytorium, dowiedziałem się o istnieniu tig-a. Wtedy jednak narzędzie nie zrobiło na mnie jakiegoś wrażenia. Chciałem czegoś więcej. Czegoś co będzie miało jakiś interfejs użytkownika prezentowany w nowym oknie. Wybrałem wtedy narzędzie, które uruchamia się po uruchomieniu polecenia gitk.
Jest ono bardzo lekkie:
du -sh /usr/bin/gitk
88K /usr/bin/gitk
Tym samym działa szybko - a jest to dla mnie priorytetem w doborze softu do codziennej pracy. Ile czasu można stracić używając wolnego oprogramowania to na pewno każdy z nas już się o tym przekonał.
Pozwolę sobie zamieścić zrzut ekranu z głównego okna kiedy to uruchamiam tig-a na jednym z moich projektów:
Opcje
tig to bardzo szybkie narzędzie terminalowe, dzięki któremu mamy dostęp do wielu rzeczy korzystając z prostych skrótów klawiaturowych.
Najważniejszym skrótem jest oczywiście dostęp do pomocy. Wchodzimy do programu i … h.
Wchodzimy tym samym do ekranu z całą listą skrótów dostępnych pod tigiem.
m view-main Show main view
d view-diff Show diff view
l view-log Show log view
t view-tree Show tree view
f view-blob Show blob view
b view-blame Show blame view
r view-refs Show refs view
s, S view-status Show status view
c view-stage Show stage view
y view-stash Show stash view
g view-grep Show grep view
p view-pager Show pager view
h view-help Show help view
Lista powyżej jest listą ekranów do których mamy dostęp za pomocą pojedynczych literek jako skrótów klawiaturowych - zwykłych literek.
Nie będę się starał opisywać całego programu, bo to nie o to chodzi - zresztą dziś zacząłem się nim interesować, więc potrzebuje jeszcze jakieś kilka tygodni codziennej pracy, aby móc się szerzej wypowiedzieć.
Nie mniej jednak zachęcam do korzystania, ponieważ dzięki tig zarządzamy repozytorium nie wpisując całych poleceń do terminala tylko korzystamy z łatwych skrótów. Nie czuję tutaj, abym nie wiedział co w danej chwili uruchomił za mnie program, tak jak ma to miejsce w tak skomplikowanych programach jak SourceTree czy chociażby GitHub for Mac.
git flow
Kolejnym narzędziem pomocnym w pracy z Git-em jest git flow. Nie jest to narzędzie zainstalowane domyślnie razem z Git-em, trzeba je zainstalować osobno (link poniżej).
git flow wymusza na nas utrzymanie porządku w branchach i tagach, nie poprzez przełączanie się bezpośrednio pomiędzy branchami, tylko według zasad zdefiniowanych w tzw. flow.
Nie mogę powiedzieć, że mam doświadczenie z takim podejściem, więc przytoczę tylko to, co Michał przekazał na szkoleniu.
Podstawową funkcjonalności jest przełączanie się pomiędzy feature-ami stworzonymi w projekcie poprzez:
git flow feature start 12345-support-sign-up
Kiedy zakończymy nad nim pracę informujemy, że feature został zakończony:
git flow feature finish 12345-support-sign-up
Wtedy taki branch zostaje zmergowany do brancha develop. Jest to branch w których nie prowadzimy żadnych prac, jest to taki kolektor, agregat, funkcjonalności realizowanych w innych branchach typu feature/xxx.
Hint: branch master jest odzwierciedleniem aplikacji na produkcji, czyli takiej która jest u klienta.
Ten rysunek przedstawia jak wygląda praca z git flow:
Bardzo ciekawą opcją jest jeszcze tworzenie release-ów aplikacji.
Z pomocą przychodzi tutaj polecenie:
git flow release start 1.0
git flow przełącza nas na specjalnego brancha, w którym możemy tworzyć kolejne rewizje (np. podmiana numerka wersji w README.md). Jest to bardzo wygodne rozwiązanie, bo jeśli nic nie musimy robić to po prostu wykonujemy finish tego procesu:
git flow release finish 1.0
Ze swojej strony bardzo zachęcam do chociażby wypróbowania takiego podejścia do zarządzania branchami w swoim projekcie.
Najlepiej jak by cały zespół projektowy wykorzystywał te narzędzie, zachowalibyśmy spójność w całym projekcie, co jest w większych projektach nie tylko wskazane.
Podsumowanie
Link do wcześniej wspomnianych rzeczy:
- Prezentacja Michała: https://www.youtube.com/watch?v=QrJ5cdX1ir4
- Repozytorium
tig-a: github.com/jonas/tig - Projekt
git flow: github.com/nvie/gitflow