Jak uprościć przepływ pracy nad rozwojem zespołu za pomocą haków Git

Jednym z głównych wymagań pracy zespołu lub projektu open source jest użycie systemu kontroli wersji (VCS). Git to darmowy i rozproszony system kontroli wersji o otwartym kodzie źródłowym do śledzenia zmian kodu źródłowego podczas tworzenia oprogramowania. Został stworzony przez Linusa Torvaldsa w 2005 roku w celu rozwoju jądra Linuksa. Jest łatwy do nauczenia i zajmuje niewiele miejsca, a jego działanie jest błyskawiczne.

Istnieje duża szansa, że ​​już korzystałeś z Gita (ponieważ jest to jedno z najpopularniejszych i najpopularniejszych narzędzi VCS dostępnych w społeczności programistów) i prawdopodobnie masz już pewną wiedzę na temat przemieszczania i zatwierdzania kodu poprzez pushowanie i pulling go ze zdalnego repozytorium. W tym artykule nie omówimy podstaw przepływów pracy git, ale skupimy się głównie na hakach git i sposobach ich wykorzystania w celu osiągnięcia lepszej współpracy w zespole. Wraz ze wzrostem rozmiarów zespołów, coraz ważniejsze staje się utrzymywanie współautorów w ryzach i utrzymywanie różnych zasad dotyczących kodu.

Czym są haki Git?

Hooki git to skrypty, które są uruchamiane, gdy w repozytorium git wykonywane są określone akcje lub zdarzenia. Te akcje dotyczą części przepływu pracy kontroli wersji, takich jak zatwierdzanie i wypychanie. Hooki mogą być naprawdę przydatne, automatyzując zadania w przepływie pracy git. Mogą na przykład pomóc nam zweryfikować składnię naszej bazy kodu na podstawie określonych reguł lub przeprowadzić kilka testów przed zatwierdzeniem naszych zmian.

Jak je ustawić?

Hooki git są wbudowaną funkcją, co oznacza, że ​​jesteśmy w stanie uzyskać do nich dostęp i zacząć z nich korzystać tak długo, jak zainicjowane zostanie repozytorium git. Przyjrzyjmy się bardziej szczegółowo, co to oznacza, próbując je ustawić.

Używając swojego ulubionego terminala, utwórz nowe repozytorium git.

 mkdir my-new-repository && cd my-new-repository git init ls -la

Zauważysz, że właśnie utworzono nowy ukryty katalog. Ten folder .git jest używany z git do przechowywania informacji związanych z repozytorium, takich jak skróty kontroli wersji, informacje o zatwierdzeniach, adresy zdalnego repozytorium i tak dalej. Jest to również folder, w którym faktycznie znajdują się hooki dla git .git/hooks . Możesz znaleźć kilka wstępnie wypełnionych przykładowych skryptów utworzonych automatycznie podczas inicjalizacji. W rzeczywistości są to skrypty, które zostaną uruchomione po wykonaniu określonych czynności.

 ls .git/hooks

Niektóre z próbek, które możesz znaleźć to:

• pre-commit.sample : wywoływany tuż przed dokonaniem zatwierdzenia.
• commit-msg.sample : edytuj plik wiadomości na miejscu.
• post-receive.sample : wywoływany po aktualizacji zdalnego repozytorium.

Pod maską

Teraz, gdy wiemy, gdzie możemy znaleźć haki, cofnijmy się o krok, aby zrozumieć, jak faktycznie działają.

Hooki git są oparte na zdarzeniach, więc dopóki wykonujemy polecenie git w procesie programowania, git sprawdzi foldery hooków w celu sprawdzenia, czy istnieje powiązany skrypt do uruchomienia. Niektóre z tych skryptów będą uruchamiane przed lub po tych akcjach przepływu programowania.

Dobrym przykładem dla nas, aby przejść, a dokładniej zrozumieć przepływ, w którym są wyzwalane hooki, jest przepływ pracy zatwierdzania, który jest dość znanym przypadkiem użycia.

Za każdym razem, gdy wprowadzamy jakiekolwiek zmiany w naszej bazie kodu, niektóre z tych powiązanych zaczepów są uruchamiane w następującej kolejności:

1. pre-commit : sprawdza migawkę, która ma zostać zatwierdzona i weryfikuje, co ma zostać zatwierdzone.
2. prepare-commit-msg : pozwala edytować domyślną wiadomość, zanim zobaczy ją autor zatwierdzenia.
3. commit-msg : ustawia komunikat zatwierdzenia na szablon.
4. post-commit : uruchamia akcję zaraz po zakończeniu zatwierdzenia i na przykład wysyła powiadomienie.

W powyższym repozytorium spróbujmy teraz dodać kilka niestandardowych skryptów przed i po zatwierdzeniu, aby lepiej zobrazować, jak faktycznie działają git hooks.

 nano .git/hooks/pre-commit

Dodaj następujący fragment:

 #!/bin/sh echo Changes are about to be committed

Upewnij się, że nasze skrypty są wykonywalne:

 chmod +x .git/hooks/pre-commit

Powtórz powyższy proces dla skryptu post-commit :

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

Teraz możemy dodać nowy plik nano index.html z małym fragmentem kodu HTML tylko w celach demonstracyjnych (nie ma potrzeby informowania o tym walidatorów HTML).

 <h1>Hello world from our new repository!</h1>

Dodamy zmiany w naszej bazie kodu poprzez przemieszczanie, a następnie zatwierdzanie tego:

 git add . git commit

Po pomyślnym przetworzeniu zatwierdzenia możemy zobaczyć następujące wyniki dwóch dodanych powyżej skryptów:

 Changes are about to be committed Changes have been committed

Zgodnie z oczekiwaniami, git wyzwalał haki w przepływie zatwierdzania. Dodane skrypty pre-commit i post-commit są uruchomione i zostaną wykonane we właściwej kolejności (na podstawie kolejności, o której wspomnieliśmy wcześniej).

To była prosta demonstracja, aby zrozumieć, jak działają skrypty przepływu pracy i jak są wykonywane. Więcej informacji na temat tego przepływu pracy można znaleźć w dokumentacji.

W powyższym przykładzie zdecydowaliśmy się napisać te dwa skrypty w bash, ale prawda jest taka, że ​​git obsługuje hooki, które można napisać w dowolnym języku skryptowym. Ruby, Python lub JavaScript są świetnymi alternatywami, o ile ustawimy poprawny ruch w pierwszym wierszu naszego skryptu wykonywalnego.

Na przykład, możemy przepisać przechwycenie pre-commit jako skrypt Node.js, jak poniżej:

 #!/usr/bin/env node console.log("Changes are about to be commited")

Lokalne i zdalne podpięcia

Hooki są oddzielone między lokalnym i zdalnym (lub klientem i serwerem). Podczas gdy lokalne podpięcia działają przed lub po określonych akcjach w lokalnym repozytorium, zdalne podpięcia są uruchamiane przed lub po wypchnięciu na serwer. Lokalne nie mogą być wykorzystywane do egzekwowania zasad, ponieważ ich charakter pozwala programistom łatwo je zmieniać. Służą one głównie do trzymania się pewnych konkretnych wytycznych, które chcemy zastosować w zespole. W przypadku, gdy chcemy być bardziej restrykcyjni i egzekwować niektóre zasady dla naszego repozytorium, rezydujemy w zdalnych podpięciach.

Lokalne haki

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

Zdalne haki

• pre-receive
• update
• post-receive

Udostępnianie haków

Git hooki polegają na udostępnianiu ich w zespole. To główny powód ich istnienia: promowanie lepszej współpracy w zespole, automatyzacja szkodliwych procesów i umożliwienie nam skupienia się tylko na ważnych częściach bazy kodu.

Jak wspomniano wcześniej, .git/hooks to folder, w którym znajdują się nasze niestandardowe hooki, ale nie jest to zbyt pomocne, gdy musimy udostępnić te skrypty w zespole, ponieważ ten folder nie jest śledzony przez git.

Dobrym podejściem do rozwiązania tego problemu jest dodanie wszystkich naszych niestandardowych podpięć do osobnego folderu w naszym repozytorium. Na przykład możemy dodać folder .githooks i zapisać tam skrypty wykonywalne. Następnie, podczas inicjalizacji projektu, możemy jawnie skopiować lub połączyć symbolicznie te skrypty do oryginalnego folderu, aby zachować nasze hooki .git/hooks .

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

Alternatywnie, jeśli używasz najnowszej wersji git (mówiąc o wersji 2.9 i nowszych), jesteśmy w stanie bezpośrednio skonfigurować ścieżkę git hooks do naszego niestandardowego folderu:

 git config core.hooksPath .githooks

Łatwość korzystania z haków Git (przypadek użycia bazy kodu JavaScript)

Istnieją narzędzia, które pomagają nam w dalszej integracji git hooków z potrzebami naszego kodu. Specjalnie dla baz kodu JavaScript jest Husky, za pomocą którego możemy łatwo dostosować akcje na zdarzeniach git poprzez konfigurację.

Na przykład, możemy łatwo lintować nasz kod lub uruchomić kilka testów w zdarzeniu pre-commit i przejść do zatwierdzenia w zależności od tego, czy linting, testowanie lub jedno i drugie zakończyło się pomyślnie, czy nie.

Można to osiągnąć, rozszerzając konfigurację package.json po prostu jako:

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

Wniosek

W tym artykule dowiedzieliśmy się, że różne akcje podejmowane w repozytorium git mogą opcjonalnie uruchamiać niestandardowe skrypty. Skrypty te mogą być pod kontrolą programisty lokalnie lub zarządzane bardziej centralnie dla zespołu lub projektu zdalnie. Dowiedzieliśmy się również, że skrypty są często pisane w skrypcie powłoki, takim jak bash, ale w rzeczywistości mogą używać prawie każdego języka skryptowego, nawet JavaScript.

Git hooki mogą być naprawdę potężną częścią dobrze zaprojektowanego przepływu pracy i zachęcam Cię do wypróbowania ich i zobaczenia, co możesz zrobić dla swoich własnych projektów.