Git Hooks를 사용하여 팀의 개발 워크플로를 쉽게 하는 방법

게시 됨: 2022-03-10
빠른 요약 ↬ 개발 워크플로는 쉽게 손에서 벗어나 팀 내에서 혼란과 마찰을 일으킬 수 있습니다. 특히 규모가 커질수록 더욱 그렇습니다. 우리의 코드 검토에서 쉼표가 누락되었거나 원격 저장소로 푸시하기 전에 실행되지 않는 테스트 실패를 알아차리는 것에 대해 너무 많은 시간을 보냈습니다. 고맙게도 이러한 마찰을 없애고 개발자의 워크플로를 보다 간단하게 만들고 실제로 가장 중요한 것에 집중하는 데 도움이 되는 도구가 있습니다. git과 git이 제공하는 후크 덕분에 개발 워크플로를 설정하고 삶을 더 쉽게 만들 수 있는 다양한 자동화가 가능합니다.

팀 또는 오픈 소스 프로젝트에서 작업하는 주요 요구 사항 중 하나는 버전 제어 시스템(VCS)을 사용하는 것입니다. Git은 소프트웨어 개발 중 소스 코드 변경 사항을 추적하기 위한 무료 오픈 소스 분산 버전 제어 시스템입니다. Linux 커널 개발을 위해 2005년 Linus Torvalds가 만들었습니다. 그것은 배우기 쉽고 번개처럼 빠른 성능으로 작은 공간을 차지합니다.

Git은 이미 개발 커뮤니티에서 사용 가능한 가장 인기 있고 잘 채택된 VCS 도구 중 하나이기 때문에 사용했을 가능성이 큽니다. 또한 푸시 및 풀링을 통해 코드를 스테이징하고 커밋하는 방법에 대한 지식을 이미 가지고 있을 가능성이 큽니다. 원격 저장소에서 가져옵니다. 이 문서에서는 git 워크플로의 기본 사항을 다루지 않지만 팀에서 더 나은 협업을 달성하기 위해 git hook과 이를 활용하는 방법에 주로 초점을 맞출 것 입니다. 팀의 규모가 커짐에 따라 기여자를 일렬로 유지하고 코드에 대한 다양한 규칙을 유지하는 것이 더욱 중요해지고 있습니다.

Git 후크란 무엇입니까?

Git 후크는 git 저장소에서 특정 작업이나 이벤트가 수행될 때 트리거되는 스크립트입니다. 이러한 작업은 커밋 및 푸시와 같은 버전 제어 워크플로의 일부에 관한 것입니다. 후크는 git 워크플로에서 작업을 자동화함으로써 정말 유용할 수 있습니다. 예를 들어, 특정 규칙에 따라 코드베이스의 구문을 검증하거나 변경 사항을 커밋하기 전에 몇 가지 테스트를 실행하는 데 도움이 될 수 있습니다.

점프 후 더! 아래에서 계속 읽기 ↓

어떻게 설정합니까?

Git hook은 내장된 기능입니다. 즉, Git 저장소가 초기화되는 한 액세스하고 사용할 수 있습니다. 설정을 시도함으로써 이것이 무엇을 의미하는지 더 자세히 살펴보겠습니다.

선호하는 터미널을 사용하여 새 git 저장소를 만듭니다.

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

새로운 숨겨진 디렉토리가 방금 생성되었음을 알 수 있습니다. 이 폴더 .git 은 버전 제어 해시, 커밋 정보, 원격 리포지토리 주소 등과 같은 리포지토리 관련 정보를 저장하기 위해 git에서 사용됩니다. 이것은 또한 git .git/hooks 에 대한 후크가 실제로 존재하는 폴더이기도 합니다. 초기화 중에 자동으로 생성된 미리 채워진 샘플 스크립트를 찾을 수 있습니다. 이것은 실제로 특정 작업 후에 트리거되는 스크립트입니다.

 ls .git/hooks

찾을 수 있는 샘플은 다음과 같습니다.

  • pre-commit.sample : 커밋 직전에 호출됩니다.
  • commit-msg.sample : 메시지 파일을 제자리에서 편집합니다.
  • post-receive.sample : 원격 저장소가 업데이트된 후 호출됩니다.

후드

이제 후크를 찾을 수 있는 위치를 알았으므로 실제로 어떻게 작동하는지 이해하기 위해 한 걸음 물러나겠습니다.

Git 후크는 이벤트 기반이므로 개발 흐름에서 git 명령을 실행하는 한 git은 실행할 관련 스크립트가 있는지 찾기 위해 후크 폴더를 확인합니다. 이러한 스크립트 중 일부는 이러한 개발 흐름 작업 전후에 실행됩니다.

후크가 트리거되는 흐름을 살펴보고 더 구체적으로 이해하기 위한 좋은 예는 매우 친숙한 사용 사례인 커밋 워크플로입니다.

코드베이스에 대한 변경 사항을 커밋할 때마다 이러한 관련 후크 중 일부가 다음 순서로 트리거됩니다.

  1. pre-commit : 커밋하려는 스냅샷을 검사하고 커밋할 내용을 확인합니다.
  2. prepare-commit-msg : 커밋 작성자가 보기 전에 기본 메시지를 편집할 수 있습니다.
  3. commit-msg : 커밋 메시지를 템플릿으로 설정합니다.
  4. post-commit : 커밋이 완료된 직후에 작업을 실행하고 예를 들어 알림을 보냅니다.
커밋 생성 과정에서 실행되는 후크
커밋 생성 프로세스 중 실행되는 후크(이미지 크레딧: Atlassian Bitbucket)(큰 미리보기)

위의 리포지토리에서 이제 git hooks가 실제로 작동하는 방식을 더 시각화하기 위해 몇 가지 사용자 지정 사전 및 사후 커밋 스크립트를 시도하고 추가해 보겠습니다.

 nano .git/hooks/pre-commit

다음 스니펫을 추가합니다.

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

스크립트가 실행 가능한지 확인하십시오.

 chmod +x .git/hooks/pre-commit

post-commit 스크립트에 대해 위 프로세스를 반복합니다.

 nano .git/hooks/post-commit
 #!/bin/sh echo Changes have been committed
 chmod +x .git/hooks/post-commit

이제 데모용으로 작은 HTML 스니펫이 있는 새 파일 nano index.html 을 추가할 수 있습니다(HTML 유효성 검사기에 이를 알릴 필요 없음).

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

스테이징을 통해 코드베이스에 변경 사항을 추가하고 다음을 커밋합니다.

 git add . git commit

커밋이 성공적으로 처리된 후 위에서 추가한 두 스크립트의 다음 출력을 볼 수 있습니다.

 Changes are about to be committed Changes have been committed

예상대로 git은 커밋 흐름에서 후크를 트리거했습니다. 추가된 pre-commit 및 post-commit 스크립트가 실행 중이며 올바른 순서(앞서 언급한 순서에 따라)로 실행됩니다.

이것은 커밋 워크플로 스크립트의 작동 방식과 실행 방식을 이해하기 위한 간단한 데모였습니다. 이 워크플로에 대한 자세한 내용은 설명서를 참조하세요.

위의 예에서 우리는 이 두 스크립트를 bash로 작성하기로 선택했지만 진실은 git이 우리가 원하는 모든 스크립팅 언어로 작성할 수 있는 후크를 지원한다는 것입니다. Ruby, Python 또는 JavaScript는 실행 가능한 스크립트의 첫 번째 줄에 올바른 shebang을 설정하는 한 훌륭한 대안입니다.

예를 들어 pre-commit 후크를 아래와 같이 Node.js 스크립트로 다시 작성할 수 있습니다.

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

로컬 및 원격 후크

후크는 로컬과 원격(또는 클라이언트와 서버)으로 구분됩니다. 로컬 후크는 로컬 저장소의 특정 작업 전후에 실행되지만 원격 후크는 서버로 푸시하기 전이나 후에 실행됩니다. 로컬 정책은 특성상 개발자가 쉽게 변경할 수 있으므로 정책을 시행하는 데 사용할 수 없습니다. 주로 팀 내에서 적용하려는 특정 지침을 고수하는 데 사용됩니다. 더 엄격해지고 저장소에 대한 일부 정책을 시행하려는 경우 원격 후크에 상주합니다.

로컬 후크

  • 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

원격 후크

  • pre-receive
  • update
  • post-receive

공유 후크

Git 후크는 팀 내에서 공유하는 것입니다. 이것이 존재하는 주된 이유입니다. 더 나은 팀 협업 촉진, 유해한 프로세스 자동화, 코드베이스의 중요한 부분에만 집중할 수 있습니다.

앞에서 언급했듯이 .git/hooks 는 사용자 정의 후크를 호스팅하는 폴더이지만 이 폴더는 git에서 추적하지 않기 때문에 팀 내에서 이러한 스크립트를 공유해야 하는 경우에는 실제로 도움이 되지 않습니다.

이 문제를 해결하는 좋은 방법은 모든 사용자 정의 후크를 저장소 내부의 별도 폴더에 추가하는 것입니다. 예를 들어, .githooks 폴더를 추가하고 거기에 실행 가능한 스크립트를 저장할 수 있습니다. 그런 다음 프로젝트 초기화 시 이러한 스크립트를 명시적으로 복사하거나 후크 .git/hooks 를 유지하기 위해 원본 폴더에 심볼릭 링크할 수 있습니다.

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

또는 최신 git 버전( 2.9 이상)을 사용하는 경우 사용자 지정 폴더에 대한 git hooks 경로를 직접 구성할 수 있습니다.

 git config core.hooksPath .githooks

손쉬운 Git Hooks(자바스크립트 코드베이스 사용 사례)

코드베이스의 요구 사항에 git hooks를 추가로 통합하는 데 도움이 되는 도구가 있습니다. 특히 JavaScript 코드베이스의 경우 구성을 통해 git 이벤트에 대한 작업을 쉽게 사용자 지정할 수 있는 Husky가 있습니다.

예를 들어, pre-commit 이벤트에서 코드를 쉽게 린트하거나 일부 테스트를 실행하고 린트, 테스트 또는 둘 다의 성공 여부에 따라 커밋을 진행할 수 있습니다.

이것은 다음과 같이 간단하게 package.json 구성을 확장하여 수행할 수 있습니다.

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

결론

이 기사에서는 git 리포지토리에서 수행된 다양한 작업이 선택적으로 사용자 지정 스크립트를 실행하도록 트리거할 수 있음을 알아냈습니다. 이러한 스크립트는 로컬에서 개발자가 제어하거나 원격에서 팀 또는 프로젝트를 위해 보다 중앙에서 관리할 수 있습니다. 우리는 또한 스크립트가 bash와 같은 쉘 스크립트로 작성되는 경우가 많지만 실제로는 JavaScript를 포함한 거의 모든 스크립팅 언어를 사용할 수 있다는 것도 배웠습니다.

Git 후크는 잘 설계된 워크플로에서 정말 강력한 부분이 될 수 있으므로 사용해 보고 자신의 프로젝트를 위해 무엇을 할 수 있는지 확인하는 것이 좋습니다.