Git Hook

Git Hook

• Git Hook 사용

  • 모노레포 구조에서 코드 검증, 빌드 자동화를 효율적으로 할 방법을 고민했습니다.
  • 프론트, 백 따로 불필요한 라이브러리 (ex. Husky) 를 사용하지 않고 공통된 git hook을 관리하여 검증을 수행합니다.
  • pre-commit: 로컬 환경에서 코드 컨벤션 및 커밋 메시지 컨벤션을 자동으로 체크합니다.
  • pre-push: 중앙에서 관리하는 git hook을 참조하여, 브랜치별로 설정된 검증 로직에 따라 빌드 과정을 수행합니다.

• 시행착오

  • git hook 내에서 백엔드 작업, 프론트엔드 작업을 구분하는 방법으로 처음에는 디렉토리 내 파일의 변경 여부를 사용했습니다.
  • origin/dev 브랜치와 비교할 때, 특정 상황에서 다른 파트의 검증이 수행되어 push에 실패하는 케이스가 생겼습니다.
  • 최종적으로 feature/be/do-something 과 같은 브랜치 name에서 be를 파싱하여 분기 처리에 사용하고 있습니다.

Pre-Commit Hook

1. 현재 브랜치 식별

   • git rev-parse --abbrev-ref HEAD로 현재 브랜치 이름을 확인한 후, 슬래시(/)를 기준으로 두 번째 부분(fe 또는 be)을 추출하여 프론트엔드와 백엔드 브랜치를 구분합니다.

2. 프론트엔드 검증 (브랜치가 fe인 경우)

   • frontend 디렉토리로 이동 후, 스테이지된 프론트엔드 파일들에 대해 ESLint의 자동 수정 기능(pnpm exec eslint --fix)을 실행합니다.
   • ESLint 검사 후, 오류가 남아있으면 커밋을 중단합니다.
   • 성공 시, 수정된 파일들을 다시 스테이지하고 커밋을 진행합니다.

3. 백엔드 검증 (브랜치가 be인 경우)

   • backend 디렉토리로 이동 후, (필요한 백엔드 검증 작업을 수행할 자리) placeholder로 처리됩니다.

Pre-Push Hook

1. 공통 작업

• 원격 branch 정보 확인:

  • push를 실행한 원격 branch 이름과 URL을 확인합니다.

• 브랜치 네이밍 검증:

  • 정규식을 사용해 브랜치 이름이 ^(feature|refactor|bugfix)/(fe|be|all)/[a-z0-9-]+$ 패턴을 따르는지 검증합니다.
  • 패턴에 맞지 않으면 에러 메시지를 출력하고 push를 중단합니다.

• 브랜치 구분:

  • 브랜치 이름에서 fe, be 또는 all 부분을 추출하여 이후 스크립트 실행 로직을 분기합니다.

---

2. 프론트엔드 검증 (브랜치의 두 번째 부분이 "fe"인 경우)

• 디렉토리 이동:

  • frontend 폴더로 이동합니다.

• 빌드 실행:

  • pnpm run build 명령어를 실행하여 프론트엔드 빌드를 수행합니다.
  • 빌드에 실패하면 에러 메시지를 출력하고 push를 중단합니다.

---

3. 백엔드 검증 (브랜치의 두 번째 부분이 "be"인 경우)

• 디렉토리 이동:

  • backend 폴더로 이동합니다.

• Spring Profile 설정:

  • 환경변수 SPRING_PROFILE이 설정되어 있지 않으면 기본값 local을 사용합니다.

• Gradle 빌드 실행 (테스트 제외):

  • ./gradlew build -x test 명령어를 실행하여 빌드를 수행합니다.
  • 빌드 실패 시 에러 메시지를 출력하고 push를 중단합니다.

• 백엔드 테스트 실행:

  • Gradle 테스트를 실행하여 테스트 결과를 확인합니다.
  • 테스트 실패 시 에러 메시지를 출력하고 push를 중단합니다.

---

4. 성공 처리

• 모든 검증을 통과하면 성공 메시지를 출력한 후, 스크립트는 정상적으로 종료됩니다.
• push가 계속 진행됩니다.