Najlepsze praktyki w Git – jak najlepiej wykorzystać (g)it

Pull, Fetch, Commit, Push, Merge, Rebase – czy te terminy zdążyły już zaistnieć w Twoim codziennym życiu? Kiedy Linus Torvalds stworzył swoją pierwszą wersję Gita, opisał ją jako „głupi tracker treści”. Szybko do przodu, to bezpłatne oprogramowanie o otwartym kodzie źródłowym jest obecnie najpopularniejszym systemem kontroli wersji.

Co to jest Git?

Czy nie chciałbyś czasem cofnąć czasu, aby podjąć lepszą decyzję lub zrobić coś inaczej? Cóż, w świecie technologii i kodowania możesz. Git to rozproszony system kontroli wersji o otwartym kodzie źródłowym, który zapisuje wersje Twojego cennego kodu za każdym razem, gdy wprowadzasz do niego jakiekolwiek zmiany/dodatki. Więc za każdym razem, gdy musisz wycofać, po prostu wybierz działającą wersję i voila! Git umożliwia również pracę w zespołach bez zakłóceń, ponieważ programiści pracują jednocześnie nad swoimi indywidualnymi kopiami lokalnymi. Każda zmiana każdego członka zespołu jest śledzona, dzięki czemu zachowuje przejrzystość w zorganizowanym przepływie. Czym więc jest GitHub? GitHub to usługa hostingu repozytorium dla Git, która ma również wiele funkcji do optymalizacji systemu kontroli wersji.
Przepływ pracy w Git

Każda organizacja ma inny przepływ pracy Git. Najbardziej udany przepływ pracy Git to taki, który zapewnia Twojemu zespołowi wystarczająco dużo miejsca na produktywność, jednocześnie maksymalizując efektywność jego wyników. Powinien być skalowalny w zależności od wielkości Twojego zespołu i powinien minimalizować liczbę konfliktów, które mogą się pojawić. Scentralizowany przepływ pracy Git to podstawa, na której budowane są inne przepływy pracy Git, takie jak przepływ pracy rozgałęziania funkcji, przepływ pracy rozwidlania, przepływ pracy Gitflow itp. Przepływ pracy należy zaplanować w celu ulepszenia i uzupełnienia kultury organizacji. Dla każdego zespołu własny Git Workflow.

Dlaczego warto korzystać z Gita?

1. Architektura rozproszona

W przeciwieństwie do scentralizowanych systemów kontroli wersji, które zmuszają programistów do dostępu do jednego centralnego repozytorium, aby móc „pobierać” i wprowadzać zmiany w poszczególnych plikach, Git stosuje podejście rozproszone. W architekturze rozproszonej każdy programista ma własne lokalne kopie całego centralnego repozytorium, co pozwala mu pracować w trybie offline, mieć dostęp do pełnej historii wersji oraz łatwego tworzenia gałęzi i łączenia.

2. Potężna wydajność

Rozgałęzianie, scalanie, zatwierdzanie itp. są naprawdę łatwe i szybkie dzięki przepływowi pracy Git dzięki inteligentnym algorytmom głębokiej wiedzy, które rozumieją wzorce dostępu do T.

3. Jest bezpieczny

Git przechowuje całą zawartość plików, w tym relacje między wersjami i katalogami, używając kryptograficznie SHA1 jako algorytmu hashtagu. Każda przypadkowa lub złośliwa zmiana kodu jest w pełni identyfikowalna.

4. Open-source

Będąc open-source, Git jest darmowy, cieszy się dobrym wsparciem społeczności, jest stale sprawdzany pod kątem jakości i jest wspierany mnóstwem dokumentacji i samouczków dla uczniów.

5. Szybsze wydania

Rozproszony rozwój Git oraz łatwe tworzenie gałęzi i tworzenie nowych funkcji zachęca programistów do częstszych zmian w zwinnym przepływie pracy

Najlepsze praktyki dla Gita

• Nowy projekt? Nowe repozytorium

Tworzenie nowego repozytorium dla każdego nowego projektu, nad którym chcesz rozpocząć pracę, ma sens organizacyjny. Po zakończeniu wepchnij go do GitHub.

• Nowa cecha? Rozgałęziać się

Teraz, gdy stworzyłeś nowy projekt, co powiesz na stworzenie nowych funkcji Git? Git Branching umożliwia tworzenie i zarządzanie zorganizowanym przepływem pracy w repozytorium. Członkom zespołu można przypisać różne gałęzie Git, co pozwala im pracować jednocześnie, ale w izolowany sposób. Zawsze podawaj sensowne gałęzie git, aby inni wiedzieli, nad czym dokładnie pracujesz.

• Zacznij dzień od bycia na bieżąco

Zawsze „przebuduj” lub pobierz najnowszą, najbardziej aktualną wersję swojego projektu (master) przed rozpoczęciem pracy nad funkcjami, które stworzyłeś/przypisałeś. Nie chcesz wprowadzać zmian w nieaktualnych plikach.

• Mieć okresowe punkty kontrolne

Nie zapisuj swoich zatwierdzeń dla dużej zmiany. Często „zatwierdzaj” drobne zmiany, aby kod był łatwiejszy do zrozumienia dla Ciebie i członków Twojego zespołu. Przywracanie i śledzenie jest również łatwiejsze, gdy zmiany są małe i częste.

• Ukryj swoją pracę

Często możesz natknąć się na sytuacje, w których pracujesz na jednej gałęzi Git, ale nagle przypomniałeś sobie, że potrzebujesz pracy na innej gałęzi, ale nie chcesz „zatwierdzać” tych w połowie wykonanych zmian. Możesz też po prostu chcieć czystej kopii roboczej. „git stash” na ratunek. Ukrywanie pozwala zapisać niedokończone zmiany na stosie, do którego możesz wrócić w dowolnym momencie!

• Zgniecenie ich zobowiązuje

Mniej zatwierdzeń w historii ułatwia monitorowanie i śledzenie, gdzie popełniłeś błąd. Jeśli chcesz zachować czystą historię zmian, ta jest dla Ciebie. Squash i scalaj wszystkie swoje zatwierdzenia w jedno, gdy żądanie ściągnięcia zostanie scalone.

• Zatwierdź wiadomości

Zawsze podawaj jasne i zrozumiałe informacje w swojej wiadomości. Zacznij od napisania krótkiego podsumowania zmian, zostaw pustą linię, a następnie szczegółowo opisz zmiany. Nie chcesz, aby Twoja historia zmian wyglądała tak :/

• Nie zmieniaj historii

Po zatwierdzeniu zmian w repozytorium nie wracaj do historii zmian. Chociaż Git pozwala to zrobić i przepisać historię publiczną, nigdy nie jest to dobrą praktyką. Zarówno dla Ciebie, jak i Twojego zespołu.

• Zastosuj łatkę Git

W sytuacjach, gdy nie masz dostępu do zapisu w repozytorium, ale nadal chcesz naprawić błąd – zastosuj łatkę Git. Zawsze pamiętaj, aby sklonować główne repozytorium, a następnie utworzyć gałąź dla nowej funkcji. Gdy masz gotowy plik .patch, zawsze wyświetlaj jego podgląd i wykonaj próbę, aby sprawdzić, czy nie ma błędów. Git zastosuje łatkę (git apply -R path/file.patch) po zakończeniu. NIE zapomnij przetestować i sprawdzić

• Nie zostawiaj żądań Pull zbyt długo

Otwarte żądanie „wyciągnięcia” może prędzej czy później wywołać konflikty. Nie zostawiaj ich bez opieki dłużej niż 2 dni. Zawsze sprawdzaj kod i jeśli można go wdrożyć, scal żądanie ściągnięcia. To nie tylko przyspieszy proces wysyłki, ale także pozwoli uniknąć konfliktów kodu.

• Lepsza organizacja dzięki narzędziom do zarządzania projektami

Jeśli korzystasz z narzędzi do zarządzania projektami, takich jak Redmine, dobrą praktyką jest używanie ich w połączeniu z Git, aby móc lepiej zarządzać wieloma członkami zespołu i ich zadaniami. Tworzenie gałęzi Git za pomocą zadania Redmine, ponieważ nazwa jest jedną z najlepszych najlepszych praktyk Git, ponieważ pozwala na lepszą przejrzystość i organizację.

• GitLab CI/CD

Korzystanie z narzędzia Continuous Integration/ Continuous Deployment, takiego jak to, umożliwia testowanie i sprawdzanie błędów i błędów oraz zapewnia zgodność ze standardami kodu. Te zadania są wykonywane po przekazaniu kodu na serwer pomostowy.