Git – po co tak się męczyć?

Git to świetny system kontroli wersji. Ostatnimi czasy zauważyłem zwiększoną aktywność tuzów polskiego światka IT w tym temacie. Edukują oni młodych programistów i bardzo dobrze. Znajomość i świadome korzystanie z systemów kontroli wersji jest nie do przecenienia nie tylko w pracy zawodowej, ale także hobbystycznej. A zatem przyczepić się mogę jedynie do poszczególnych tematów tej edukacji 🙂

Nie można także zapomnieć, że github – jeden z najpopularniejszych hostingów jest oparty właśnie o Gita. Na Githubie zaś znaleźć można firmy począwszy od najmniejszych, po gigantów pokroju Microsoftu, Facebooka czy Google.

Skoro więc mamy już tak wiele dowodów na potwierdzenie dominacji tego systemu, siadamy do komputera w poszukiwaniu materiałów.

I pierwsze co znajdziemy, to pewnie dokumentacja, która została nawet częściowo spolszczona. Swego czasu przebrnąłem przez nią i muszę przyznać, że jak na dokumentację jest całkiem jasno i przyjemnie napisana. Jednak w dobie tak szybkiego przyswajania informacji duża część ludzi nie znajdzie czasu na poznanie całego systemu i będzie chciała znaleźć rozwiązania podstawowych problemów – jak wepchnąć swoją pracę do repozytorium, jak ją pobrać, wydzielić i scalić gałęzie – tego typu rzeczy.

Natkną się zatem prędzej czy później na blogi prowadzone przez pasjonatów (tzw. geeków). I zrobią sobie krzywdę.

Spieszę z odpowiedzią na cisnące się na usta pytanie: „co ty chrzanisz?”. A tak. I chyba każdy z nas doświadczył kiedyś czegoś podobnego. Zadaj pytanie o dobre kolumny na forum audiofilskim. Wszystko poniżej 20k to „szajs”. Zadaj pytanie o dobrą lustrzankę na forum fotograficznym – podobne odpowiedzi. Nawet pytając o głupią pralkę dowiesz się niestworzonych rzeczy, ponieważ ludzie tam piszący tylko tym żyją. Dla nich „najlepsze” oznacza „niemalże idealne” – przynajmniej w ich mniemaniu.

Zadając geekom pytania spoedziewaj się geekowskich odpowiedzi

To chyba nie dziwi? Zadając (nawet pasywnie, przez poszukiwania na blogach) pytania gitowym geekom otrzymasz odpowiedzi dopasowane do nich i ich potrzeb (rzeczywistych bądź wyimaginowanych, ale to temat na utyskiwania innego rodzaju). Jeżeli nie jesteś jednym z nich – a jeżeli to czytasz, to pewnie nie jesteś, to czym prędzej zejdź z tej drogi.

Aliasy gitowe to nie najwspanialszy wynalazek ostatniej dekady

Mimo, że to właśnie będą starali Ci się wperswadować. Przerośnięte do granic możliwości strony zawierające dziesiątki poleceń, których koniecznie musisz używać i jeszcze bardziej musowo – nauczyć się na pamięć. Konsola to Twój przyjaciel. Wszystko z palca, bo nie możesz stracić cennej sekundy na kliknięcie myszką. Bla, bla, bla.

Fragment historii repozytorium przedstawiony w konsoli

To wszystko nieprawda

Komendy to ostatnia rzecz, którą musisz opanować. Tworzenie aliasów jest zbędne.

Ten sam fragment historii repozytorium przedstawiony w SmartGit

1. Przede wszystkim zrozum, jak działa kontrola wersji.
2. Zainstaluj SmartGita. To narzędzie bezpłatne dla całkiej sporej grupy ludzi – jest duża szansa, że do niej należysz.Ten sam fragment historii repozytorium przedstawiony w SmartGit
3. Załóż repozytorium – to ze dwa kliknięcia i przerób pierwsze strony wspomnianej już gitowej dokumentacji. Jest tam wszystko, czego Ci potrzeba, aby zrozumieć jak to wszystko działa. Opisano tam najważniejsze pojęcia – definicje gałęzi, referencji, tagów.
4. Poczytaj o tzw. „git flow”.
5. Pobaw się w którejś z piaskownic. O jednej z nich pisałem w poście o bezpiecznym gitowaniu.
6. Korzystaj ze SmartGita w swojej codziennej pracy i nie daj sobie wmówić, że jesteś z jakiś sposób gorszy, jeżeli nie znasz polecenia log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate(lub innego, równie użytecznego, np. listującego wszystkie Twoje gitowe aliasy :P). 

PS. Oczywiście śmieję się odrobinę. Wszystko jest dla ludzi i potrafię sobie wyobrazić kogoś, kto potrzebuje mistrzostwa w używaniu wiersza poleceń – a to pracuje w megawielkim projekcie, a to z innych przyczyn, ale dla zwykłego zjadacza chleba, przeciętnego programisty, zaczynającego pracę w przeciętnym zespole d/s aplikacji biznesowych dużo ważniejsze jest zrozumienie procesów, niż użeranie się z narzędziami, które są tylko… no właśnie – narzędziami. I każdy powinien używać takich, jakie wydają mu się najlepsze).