Implementowanie punktów zaczepienia usługi Git

Ukończone

Ustalanie priorytetów jakości kodu w procesie programowania powinno rozpoczynać się od lokalnego tworzenia kodu. Ważne jest, aby zidentyfikować możliwości tej praktyki jeszcze przed rozpoczęciem żądań ściągnięcia w celu wykrywania i rozwiązywania potencjalnych problemów z jakością kodu.

Haki Git oferują świetną okazję. Służą one jako mechanizm wykonywania skryptów niestandardowych w odpowiedzi na znaczące zdarzenia w cyklu życia usługi Git, takie jak zatwierdzenia, scalania i wypychania. Skrypty znajdujące się w katalogu .git\hooks repozytorium zapewniają praktycznie nieograniczoną elastyczność automatyzowania zadań tworzenia oprogramowania i wymuszania standardów programowania.

Jak zaimplementować elementy zaczepienia usługi Git

Zacznijmy od eksplorowania punktów zaczepienia git po stronie klienta. Przejdź do katalogu .git\hooks repozytorium — znajduje się tam wiele plików z rozszerzeniem sample. To rozszerzenie nie tylko wskazuje ich przeznaczenie, ale także skutecznie zapobiega ich uruchamianiu. Nazwy plików określają akcje usługi Git, które wyzwalają ich wykonywanie po usunięciu sample rozszerzenia.

Zrzut ekranu przedstawiający pliki punktów zaczepienia usługi Git na potrzeby automatyzacji.

Zmień nazwę pliku przed zatwierdzeniem sample na wstępne zatwierdzenie. Jak wskazuje nazwa pliku, skrypt, który zawiera, zostanie uruchomiony za każdym razem, gdy wywołasz akcję zatwierdzenia git. Zatwierdzenie następuje tylko wtedy, gdy skrypt przed zatwierdzeniem zakończy działanie z wartością zwracaną przez 0.

Należy jednak pamiętać, że domyślnie nie będzie to działać zgodnie z oczekiwaniami w żadnym z systemów operacyjnych Windows. Często pomijany powód tego zachowania to pierwszy wiersz skryptu:

#!/bin/sh

W systemach operacyjnych Linux #! prefiks wskazuje moduł ładujący programu, że pozostała część pliku zawiera skrypt do zinterpretowania, a /bin/sh jest pełną ścieżką do interpretera, który powinien być używany.

Usługa Git dla systemu Windows obsługuje polecenia powłoki Bash i skrypty powłoki, ale nie jest zgodna z tą samą konwencją podczas projektowania ścieżek systemu plików. Zamiast tego należy podać pełną ścieżkę do pliku sh.exe, zaczynając od litery dysku.

Istnieje jednak dodatkowe zastrzeżenie, które wynika z faktu, że usługa Git dla systemu Windows domyślnie jest instalowana w katalogu C:\Program Files. Ponieważ ten katalog zawiera spację w nazwie, wynikowa ścieżka do pliku sh.exe będzie interpretowana jako dwie oddzielne ścieżki, co spowoduje awarię. Aby tego uniknąć, należy dodać pojedynczy ukośnik odwrotny (\) przed spacją, aby służyć jako znak ucieczki. W przypadku korzystania z 64-bitowej wersji narzędzia Git dla systemu Windows pierwszy wiersz skryptu powinien mieć następujący format:

#!C:/Program\ Files/Git/usr/bin/sh.exe

Jak to zrobić

Jak można używać nowo odnalezionych funkcji skryptów wstępnego zatwierdzania usługi Git? Jak zatrzymać się przed przypadkowym wyciekiem wpisów tajnych do usługi GitHub?

Użyjmy elementu zaczepienia git, aby zeskanować kod zatwierdzony w repozytorium lokalnym pod kątem określonych słów kluczowych. Zastąp zawartość pliku powłoki przed zatwierdzeniem następującym kodem:

#!C:/Program\ Files/Git/usr/bin/sh.exe
matches=$(git diff-index --patch HEAD | grep '^+' | grep -Pi 'password|secret')
if [ ! -z "$matches" ]
then
  cat <<\EOT
Error: Words from the blocked list were present in the diff:
EOT
echo $matches
exit 1
fi

Ten przykład ma na celu zilustrowanie koncepcji, a nie w pełni funkcjonalnego rozwiązania, więc lista słów kluczowych jest celowo trywialna. Używając wyrażeń regularnych, można znacznie rozszerzyć jego zakres i elastyczność. Istnieje również możliwość odwoływania się do pliku zewnętrznego, co znacznie uprościłoby ciągłą konserwację.

Zasady działania

Po wywołaniu skrypt zaczepienia wstępnego zatwierdzania używa różnic git i poleceń grep do identyfikowania słów kluczowych lub wzorców w przyrostowych zmianach w kodzie, który jest zatwierdzany. Jeśli zostaną wykryte jakiekolwiek dopasowania, skrypt generuje komunikat o błędzie i uniemożliwia zatwierdzenie.

Jest więcej:

Inne, typowe przypadki użycia skryptów zaczepienia przed zatwierdzeniem obejmują formatowanie kodu, linting lub uruchamianie testów niestandardowych, aby upewnić się, że zatwierdzenie jest zgodne ze standardami projektu. Polecenie Prepare-commit-msg jest uruchamiane przed uruchomieniem edytora komunikatów zatwierdzenia. Umożliwia dynamiczne generowanie komunikatów zatwierdzeń w celu wymuszania konwencji nazewnictwa, takich jak użycie wyznaczonych prefiksów (na przykład wyczyn: dla funkcji lub poprawki: w przypadku poprawek błędów).

Na przykład następujący skrypt prepare-commit-msg automatycznie poprzedza nazwę bieżącej gałęzi komunikatem zatwierdzenia podczas tworzenia nowego zatwierdzenia. Modyfikuje plik komunikatu zatwierdzenia ($1), dodając nazwę gałęzi, po której następuje dwukropek i spacja na początku pliku.

#!C:/Program\ Files/Git/usr/bin/sh.exe
# Get the current branch name
branch_name=$(git branch --show-current)
# Check if the commit message file exists
if [[ -f "$1" ]]; then
  # Prepend the branch name to the commit message
  sed -i "1s/^/$branch_name: /" "$1"
fi

Skrypty po zatwierdzeniu są wykonywane po zakończeniu zatwierdzania. Może służyć do wyzwalania powiadomień lub generowania dokumentacji.

Na przykład następujący skrypt wysyła powiadomienie e-mail do wyznaczonego adresata po każdym zatwierdzeniu. Skrypt można dostosować, modyfikując adres e-mail adresata, serwer SMTP oraz temat i treść wiadomości e-mail. Ponadto może być konieczne skonfigurowanie systemu w celu wysyłania wiadomości e-mail przy użyciu polecenia cmdlet programu PowerShell Send-MailMessage lub użycia innej metody wysyłania powiadomień w zależności od środowiska i wymagań.

#!C:/Program\ Files/Git/usr/bin/sh.exe
# Set the recipient email address
$recipient="your@email.com"
# Set the subject of the email
$subject="Git Commit Notification"
# Set the body of the email
$body="A new commit has been made to the repository."
# Send the email notification
Send-MailMessage -To $recipient -Subject $subject -Body $body -SmtpServer "your.smtp.server"

Warto zauważyć, że folder .git\hooks repozytorium nie jest zatwierdzony do kontroli źródła. Możesz się zastanawiać, czy istnieje sposób udostępniania skryptów opracowanych przez innego członka zespołu deweloperskiego. Dobrą wiadomością jest to, że począwszy od usługi Git w wersji 2.9, można mapować haki git na folder, który może zostać zatwierdzony w kontroli źródła. Można to zrobić, aktualizując konfigurację ustawień globalnych dla repozytorium Git:

Git config --global core.hooksPath '~/.githooks'

Jeśli kiedykolwiek musisz zastąpić haki Git skonfigurowane po stronie klienta, możesz to zrobić za pomocą przełącznika bez weryfikacji:

Git commit --no-verify

Haki po stronie serwera

Podczas gdy zaczepienia git po stronie klienta oferują niezawodne możliwości zwiększania przepływu pracy programowania, usługa Azure Repos udostępnia również haki po stronie serwera w celu dalszego rozszerzania procesu programowania, w tym obsługi tworzenia żądań ściągnięcia. Aby uzyskać więcej informacji, zobacz dokumentację zdarzeń punktów zaczepienia usługi Azure Repos Service.