Skip to content

Latest commit

 

History

History
33 lines (27 loc) · 2.68 KB

File metadata and controls

33 lines (27 loc) · 2.68 KB
name git-commit
description 사용자가 현재 git 저장소의 변경 사항 전체 또는 지정한 일부를 커밋해 달라고 요청할 때 사용합니다.

변경 범위 결정

  1. 진행 중인 merge, rebase, cherry-pick, revert 또는 unmerged 변경이 있으면 중단하고 상태를 보고한다.
  2. 사용자가 지정한 범위를 사용하며, 지정하지 않으면 commit 가능한 모든 변경을 대상으로 한다.
  3. references/exclusions.md를 읽는다. 저장소 루트를 기준으로 패턴을 순서대로 gitignore 규칙에 따라 적용한다.
  4. 범위 내 staged, unstaged, untracked 변경을 확인하고 제외된 경로는 staged 상태이거나 사용자가 명시적으로 요청했어도 절대 후보로 삼지 않는다.
  5. 후보가 없으면 빈 commit을 생성하지 않고 중단한 뒤 결과를 보고한다.

commit 생성

  1. 프로젝트 규칙에서 commit 단위와 메시지가 각각 정해졌는지 먼저 판단한다. 정해지지 않은 범주가 있을 때만 references/guidelines.md의 해당 부분을 읽고 적용한다.
  2. 확정된 모든 commit을 중간 승인이나 계획 확인 없이 생성한다.
  3. 각 commit에는 배정된 변경만 준비하고, worktree나 다른 변경의 staging 상태는 수정하지 않는다. commit 직전에 staged diff가 해당 commit에 배정된 변경만 포함하고 제외 경로가 없는지 확인한다.
  4. git commit을 별도 명령으로 실행해 종료 상태를 직접 확인하고 hook이 실행되도록 한다. 실패하면 재시도하거나 우회하지 않고 중단하며, 앞서 성공한 commit은 보존한다.
  5. commit 후에는 나머지 변경과 staging 상태가 보존됐는지 확인한다.

제한

이 제한은 commit 단계에 적용한다. 요청에 구현도 포함되어 있으면 해당 구현과 검증을 완료한 뒤 commit 단계로 진행한다.

  • commit 생성에 필요한 확인과 git 작업만 수행한다. 테스트, lint, build 등의 프로젝트 명령이나 whitespace 검사는 실행하지 않는다.
  • 절대 --no-verify, --amend를 사용하거나 git 설정을 변경하지 않는다.
  • 로컬 commit만 생성하며 push, branch 생성 또는 전환, tag 생성, PR 생성은 하지 않는다.
  • API key, token, credential, private key 등의 민감정보는 절대 commit하지 않는다.

결과

  • 생성된 각 commit을 - `<짧은 hash>` <subject> 형식으로 한 줄씩 보고한다.
  • 제외되었거나 요청 범위 밖이거나 그 밖의 이유로 commit되지 않고 남은 변경을 보고한다.
  • 실패하면 실패한 단계와 원인을 보고한다.
  • 실행한 git 명령과 내부 판단 과정은 생략한다.