Kilka praktycznych porad do pracy z gitem.
Jesteś początkującym użytkownikiem gita albo dopiero chcesz się go nauczyć? Zajrzyj tutaj.
Wysyłaj commity możliwie często
Git bierze pełną odpowiedzialność za Twoje dane tylko wtedy, gdy się „zcommitujesz”. Jeśli nie będziesz pamiętał o wysłaniu commita a potem zrobisz z kodem coś źle przemyślanego, możesz wpaść w kłopoty. Posiadanie okresowych punktów kontrolnych daje programiście szansę na cofnięcie się w przeszłość i zrozumienie co zostało zepsute.
Ludzie to wiedzą a mimo to opierają się takiej praktyce bo jest to brzydkie, ogranicza funkcjonalność git-bisection, jest mylące dla obserwatorów a wręcz może prowadzić do oskarżeń o głupotę ze strony co mniej kulturalnych kolegów ;-) Cóż, jeśli po zakończeniu pracy nad projektem chcesz udawać wobec zewnętrznego świata, że Twój kod wypłynął z Twojego umysłu do repozytorium od razu całkowicie perfekcyjny, z każdą koncepcją w pełni przemyślaną i zaplanowaną, nie ma problemu. Git wspiera takie pudrowanie repozytorium – wystarczy zobaczyć potem pobawić się w rebase i git-bisect. Nie pozwól jednak, aby jutrzejsze piękno powstrzymało Cię od wysyłania dzisiejszych commitów, które mogą uratować Ci wiele godzin pracy.
Nie panikuj
Tak długo, jak długo commitowałeś swoją pracę (lub w wielu przypadkach przynajmniej dodałeś pliki za pomocą git add), twoja praca nie zostanie utracona przez co najmniej dwa tygodnie, chyba że naprawdę się postarasz (uruchamiając polecenia, które ręcznie ją usuwają).
Próbując znaleźć utracone commity, najpierw upewnij się, że nie stracisz żadnej bieżącej pracy. Powinieneś zatwierdzić swój obecny kod (ew. zrobić stash) przed podjęciem jakichkolwiek działań naprawczych, które mogą zniszczyć to nad czym aktualnie pracujesz i być może wykonać kopie zapasowe. Po znalezieniu commitów możesz wtedy bezstresowo wykonać reset, rebase, cherry-pick, merge lub w inny sposób zrobić to, co jest konieczne, aby uzyskać pożądaną historię commitów i drzewko pracy.
Istnieją trzy miejsca, w których „utracone” zmiany mogą się ukrywać. Mogą znajdować się w reflogu (git log -g), mogą znajdować się w zagubionych i znalezionych (git fsck –unreachable) lub mogły zostać ukryte (git stash list).
No i oczywiście prawa Murphy’ego uczą nas, że jest jeszcze taka możliwość iż Twoje commity wcale nie zostały utracone. Być może commit zostało wykonany na innej gałęzi niż na tej, o której myślałeś. Użyj git log -Sfoo --all i gitk --all --date-order aby spróbować znaleźć swoje zmiany w znanych gałęziach.
Wykonuj kopie zapasowe
Wszyscy zawsze zalecają tworzenie kopii zapasowych jako najlepszą praktykę, nic odkrywczego. Ale wiemy też, że gdy naprawdę potrzebujesz sięgnąć po backup, okazuje się że nie masz żadnego lub akurat wykonanego w tej dacie, na której Ci zależy. Na pewno pokrzepi Cię w takiej chwili myśl, że masz – wręcz wysoce nadmiarowy i rozproszony - system tworzenia kopii zapasowych ad-hoc! Dzieje się tak, ponieważ zasadniczo każdy clone jest kopią zapasową. W wielu przypadkach można użyć klona do eksperymentów z gitem, aby udoskonalić swoją metodę przed wypróbowaniem jej w rzeczywistości. Jest to najbardziej przydatne w przypadku poleceń git filter-branch i podobnych, w których dochodzi do trwałego zniszczenia historii bez możliwości odwrotu. Mimo to prawdopodobnie potrzebujesz również bardziej formalnego systemu kopii zapasowych.
Tradycyjne kopie zapasowe są nadal odpowiednią praktyką a klony i tak nie zapisują konfiguracji git, katalogu roboczego i indeksu czy niestandardowych odnośników. Korzystanie z tarball, cp, rsync, zip, rar czy podobnych narzędzi pozwala uzyskać idealną kopię zapasową. O ile bazowy system plików nie zmieni radykalnie kolejności operacji wejścia-wyjścia gita i nie ma dużego opóźnienia między skanowaniem katalogu a ich pobraniem, wynikowa kopia .git powinna być spójna w prawie wszystkich okolicznościach.
