에이전트에게 일을 시키면 어디까지 하고 멈춰야 하는가.
안 A 고친다 → 커밋한다 → 결과를 보여준다
안 B 고친다 → 멈춘다 → 결과를 보여준다 → 커밋하라면 커밋한다
한 글자 차이 같지만 되돌리는 비용이 다르다. 안 A에서 리뷰에 걸리면 --amend나 추가 커밋이 필요하고, 무엇이 바뀌었는지 보려면 커밋 범위를 짚어야 한다. 안 B는 git diff 하나로 끝난다.
그런데 이것만이 이유였다면 “작업 브랜치에서는 amend가 싸니 커밋하고 고치면 되지 않나” 로 뒤집힌다. 실제로 뒤집히지 않는 이유는 따로 있고, 이 글은 그걸 적는다.
먼저: 여기서는 에이전트가 여럿이고 병렬로 돈다
이 프로젝트에는 Claude, Codex, Copilot이 같은 저장소에서 돈다. 하루에도 서로 다른 세션이 각자 작업을 밀어넣는다.
그래서 “지금 무엇이 어디까지 됐는가”가 사람 머릿속에만 있으면 안 된다. 세션이 끊기면 그 상태도 같이 사라지고, 다음 요청이 어긋난 전제 위에서 시작된다.
같은 사실이 이 저장소의 표준을 바꾼 게 이번이 처음이 아니다. 스키마 마이그레이션 표준이 파일 이름을 일련번호에서 타임스탬프로 바꾼 이유가 그것이었다.
마이그레이션을 만드는 주체가 사람만이 아니었다 — AI 에이전트가 병렬로 돈다.
두 번째로 같은 조건이 판단을 바꿨다. 이번엔 파일 이름이 아니라 작업 절차 쪽이다.
원칙 1. 커밋 직전에 멈춘다
정해야 했던 건 이거였다 — 에이전트가 커밋까지 하는가, 그 앞에서 멈추는가.
안 A — 커밋하고 나서 보여준다
얻는 것은 왕복이 한 번 줄어든다는 것이다. “커밋해”라고 다시 말할 필요가 없다.
버린 이유는 리뷰에서 고칠 게 나오면 히스토리를 손봐야 한다는 것이다. --amend로 덮거나 추가 커밋을 얹게 되고, 확인 비용도 커진다. 커밋 전이면 git diff 하나면 되는데 커밋 뒤에는 범위를 짚어야 한다.
안 B — 커밋하고, 문제가 있으면 amend나 reset으로 고친다
작업 브랜치에서는 히스토리를 고치는 값이 싸다. 아직 아무도 안 본 커밋이니 덮어도 된다. 얻는 것은 안 A와 같으면서 히스토리 오염 걱정이 없다는 것이다.
버린 이유는 여기서 갈린다. 커밋해버리면 멈출 이유가 사라진다.
안 C — 멈추지 않고 커밋 메시지에 요약을 충분히 담는다
얻는 것은 기록이 히스토리에 남는다는 것이다. 나중에 git log로 되짚을 수 있다.
버린 이유는 읽는 시점이 이미 커밋 뒤라는 것이다. 요약이 아무리 좋아도 그건 보고가 아니라 사후 기록이다.
골랐다 — 커밋 직전에 멈춘다. 안 B와 안 C가 못 지켜주는 게 하나 있다.
대가는 왕복이 한 번 는다는 것이다. 그 대가를 무엇과 바꿨는지가 다음 절이다.
원칙 1-1. 멈추는 이유는 둘이고, 각각이 다른 안을 죽인다
이 표준이 처음 만들어질 때 적힌 이유는 하나였다 — 품질 검토. 잘못된 결과물이 히스토리에 남기 전에 잡는다는 것.
그것만으로는 안 B가 안 죽는다. 작업 브랜치에서 amend는 싸니까.
두 번째 이유가 있어야 죽는다 — 흐름 파악. 사용자가 에이전트들이 업무를 어디까지 진행했는지 알아야 하고, 그게 없으면 프로젝트가 산으로 갈 가능성이 높다.
커밋은 에이전트가 자기가 한 일을 강제로 드러내야 하는 유일한 자리다.
거기서 안 멈추면 요약을 내놓을 계기가 아예 없다.
| 안 | 품질 검토만 이유라면 | 흐름 파악까지 이유라면 |
|---|---|---|
안 B 커밋하고 amend |
통할 수도 있다 | 커밋하면 멈출 계기가 사라진다 |
| 안 C 메시지에 요약 | 부분적으로 답한다 | 읽는 시점이 이미 커밋 뒤다 |
이유를 하나만 적어두면 6개월 뒤에 안 B가 다시 살아난다. 그래서 둘을 함께 적는다.
원칙 2. git add도 하지 않는다
멈추기로 했으면 어디서 멈출지가 남는다. 스테이징 직전이다.
# 스테이징하면 이게 비어 보인다
git diff
# 스테이징한 것까지 보려면 명령이 하나 더 필요하다
git diff --cached
작업 트리에 그대로 두면 git diff 하나로 전부 보인다. 리뷰하는 쪽이 명령 두 개를 기억해야 하는 상태를 만들지 않는다.
대신 새로 만든 파일은 git diff에 안 잡힌다. 추적되지 않기 때문이다. 그래서 멈출 때 새로 만든 파일은 새로 만들었다고 따로 표시한다. 이걸 빠뜨리면 리뷰하는 쪽은 있는 줄도 모르는 파일을 그대로 커밋하게 된다.
원칙 3. 멈출 때 무엇을 내놓는지 고정한다
"커밋해도 되겠습니까"만 묻고 넘어가면 멈춘 값어치가 없다. 멈춤은 승인을 받는 자리가 아니라 상태를 드러내는 자리다.
내놓는 것을 목록으로 고정한다.
- 판 브랜치 이름과 딴 자리
- 바꾼 파일 목록 — 새로 만든 파일은 그렇다고 표시
- 파일마다 무엇을 왜 바꿨는지 한 줄
- 확인용 명령 (
git status,git diff) - 커밋 메시지 초안
- 작업 중에 임의로 판단한 것과 확신이 없는 것
마지막 항목이 핵심이다. 요청에 안 적혀 있어서 에이전트가 스스로 정한 것들이 여기서 드러난다. 안 적으면 그 판단은 코드에만 남고 사람은 모른 채 지나간다.
원칙 4. 커밋·푸시·PR을 각각 따로 요청받는다
“커밋해”를 “커밋하고 푸시하고 PR 열어”로 읽지 않는다.
이유는 원칙 1과 같다. 단계마다 멈추는 자리가 있어야 흐름이 보인다. 한 번에 끝까지 가면 중간 상태를 볼 지점이 사라진다.
그리고 되돌리는 비용이 단계마다 다르다.
커밋만 했다 로컬에서 얼마든지 고친다
푸시까지 했다 다른 세션이 이미 당겨갔을 수 있다
PR 까지 열었다 닫는 흔적이 남는다
뒤로 갈수록 비싸지는데 앞에서 한꺼번에 승인할 이유가 없다.
열린 PR도 에이전트가 머지하지 않는다. 머지는 사람이 한다.
원칙 5. 문서만으로는 안 지켜져서 세 층으로 못 박는다
규칙을 스킬에 적는 것만으로는 안 됐다. 스킬은 description이 걸릴 때만 로드된다. 로드가 안 되면 에이전트는 그냥 커밋한다.
3단 구조의 판단 그대로 층을 나눴다.
| 층 | 무엇을 담나 | 언제 들어오나 |
|---|---|---|
1단 CLAUDE.md |
세 줄로 못 박은 규칙 | 판단 없이 매 요청에 |
| 2단 훅 | 통합 브랜치 커밋 차단 | git commit·git push 직전 |
| 3단 스킬 | 절차 전문 | 필요할 때 |
1단에 올리는 것은 문서에 적는 것과 다르다. 스킬은 모델이 부를지 판단하지만 1단은 판단이 없다. 이 표준은 “말 안 하면 기본값으로 어기는” 규칙의 전형이라 1단 자리가 맞다.
그 위에 훅을 얹은 이유는 1단도 읽는 것과 실행하는 것이 다르기 때문이다. 읽고도 커밋할 수 있다.
원칙 6. 훅은 통합 브랜치만 막고 작업 브랜치는 막지 않는다
훅을 어디까지 막게 할지가 갈림길이었다.
안 — 모든 커밋을 막는다. 그러면 “커밋해”라고 해도 안 된다. 뚫리지 않는 훅은 규칙이 아니라 고장이다.
골랐다 — 통합 브랜치 위의 git commit·git push와, 통합 브랜치를 대상으로 지목한 git push만 막는다.
main 위에서 git commit 차단
main 위에서 git push 차단
작업 브랜치에서 git push origin HEAD:main 차단
작업 브랜치에서 git commit 통과
main 위에서 git status / git diff 통과
작업 브랜치의 커밋은 문서가 맡고 훅은 안 맡는다. 거기서 멈추는 건 원칙 1의 규칙이지 기계가 강제할 일이 아니다 — “커밋해”라고 했을 때 뚫려야 하니까.
반대로 통합 브랜치 직커밋은 사람이 허락해도 잘못이라 예외를 둘 자리가 없다. 그래서 그쪽만 기계로 옮겼다.
임시 저장소에서 PowerShell과 bash 두 스크립트에 같은 입력을 넣고 종료 코드를 비교해 11개 케이스 전부 통과를 확인했다. 그 과정에서 둘이 잡혔다.
- 한글이 깨졌다. PowerShell 5.1은 BOM 없는
.ps1을 ANSI로 읽고 출력도 CP949로 낸다 .sh가git commit을 못 잡았다.git[[:space:]]가 공백을 먹어 뒤의 매칭이 실패했는데,git add . && git commit은&&분기로 우연히 통과해 겉보기엔 멀쩡했다
원칙 7. dev가 없는 저장소는 main에서 딴다
처음 규칙은 “dev에서 딴다. dev가 없으면 어디서 딸지 사용자에게 묻는다. main에서 바로 따지 않는다” 였다.
이게 실제로 막혔다. 이 블로그 저장소에는 dev가 없는데, 그러면 어디로도 PR을 열 수 없는 상태가 된다. 묻는다고 답이 생기지도 않는다 — 통합 브랜치가 하나뿐이라 답은 이미 정해져 있다.
그래서 dev가 없으면 main에서 딴다. 물을 것이 없다.
그리고 금지 대상을 옮겼다.
before main 으로 직접 PR 을 열지 않는다 ← dev 없으면 막다른 길
after 작업 브랜치를 통합 브랜치에
로컬에서 직접 머지하지 않는다 ← 진짜 막아야 할 것
진짜 문제는 PR을 어디로 여느냐가 아니라 PR 없이 머지하는 쪽이었다. 실제로 로컬 main에 머지했더니 훅이 main 푸시를 막아서 올라가지도 못하고 히스토리만 갈렸다.
원칙 8. 브랜치는 「내가 아닌 누군가가 본다」가 있을 때만 판다
여기가 이 표준의 마지막 갈림길이고, 적용 범위를 가른다.
멈추는 것과 브랜치를 파는 것은 다른 이유로 있는 장치다.
멈춘다 품질 검토 + 흐름 파악 ← 혼자여도 필요하다
브랜치·PR 내가 아닌 누군가가 본다 ← 그 누군가가 없으면 빈 절차다
이 블로그 저장소는 혼자 쓰는 기록 공간이다. 실제로 이 표준대로 브랜치를 파고 PR을 열어봤더니, 내가 열고 내가 머지하는 왕복만 남고 얻은 것이 하나도 없었다.
그래서 이 저장소는 멈추는 것만 지키고 브랜치는 안 판다. main에서 바로 고치고 바로 푸시한다. 배포본(coding-standards/)은 그대로 브랜치·PR을 요구한다 — 여럿이 쓰는 프로젝트를 전제하기 때문이다.
main 커밋을 막는 훅도 배포본에만 걸어둔다.
대가는 다른 세션과 부딪히는 것이다. 브랜치가 없으면 충돌을 막을 게 없으므로 푸시 전에 git pull --ff-only로 당기는 것을 규칙에 넣었다.
둘은 같아야 하는 규칙이 아니라 전제가 다른 규칙이다.
판단 기준 정리
| 질문 | 답 | 왜 |
|---|---|---|
| 어디까지 하고 멈추나 | 커밋 직전 | 커밋하면 보고할 계기가 사라진다 |
왜 amend로 고치면 안 되나 |
품질은 되고 흐름이 안 된다 | 이유가 둘이라 안 하나로는 못 죽인다 |
git add는 하나 |
안 한다 | git diff 하나로 다 보여야 한다 |
| 커밋·푸시·PR을 묶어도 되나 | 각각 따로 | 되돌리는 값이 단계마다 다르다 |
| 훅이 어디까지 막나 | 통합 브랜치만 | 뚫리지 않는 훅은 고장이다 |
dev가 없으면 |
main에서 딴다 |
통합 브랜치가 하나뿐이면 물을 게 없다 |
| 브랜치를 꼭 파나 | 볼 사람이 있을 때만 | 혼자면 PR이 빈 절차가 된다 |
이 표준을 정하기까지
이 글은 표준보다 늦게 쓰였다. 규칙과 훅이 먼저 만들어졌고 글이 없었다 — 이 저장소 규칙(표준을 만들면 다섯 파일을 같은 커밋에)을 어긴 상태로 배포까지 나갔다. 그래서 「정하기까지」가 두 세션에 걸쳐 있다.
처음 이유는 하나였다. 커밋한 뒤에 보여주면 리뷰에서 고칠 게 나왔을 때 --amend나 추가 커밋이 필요하고 확인 비용도 커진다는 것. 커밋 전이면 git diff 하나로 끝난다.
스킬만으로는 안 지켜진다는 걸 만들면서 알았다. 스킬은 description이 걸릴 때만 로드되고, 로드가 안 되면 에이전트는 그냥 커밋한다. 그래서 1단 세 줄과 훅이 얹혔다. 훅을 어디까지 막게 할지에서 선이 그어졌다 — 작업 브랜치 커밋까지 막으면 “커밋해”가 안 되니, 통합 브랜치만 막고 나머지는 문서가 맡는다.
훅을 검증하다 두 가지가 잡혔다. PowerShell 5.1의 BOM·CP949 문제와, bash 정규식이 git commit을 못 잡는데 && 분기 덕에 겉보기엔 통과하던 것. 두 번째는 테스트가 없었으면 못 봤을 종류다.
그리고 이 표준을 실제로 쓰다가 세 가지가 드러났다. 여기서부터가 다음 세션이다.
첫째, dev가 없으면 막다른 길이었다. 이 저장소가 그렇다. “묻는다”는 규칙이 있었지만 통합 브랜치가 하나뿐이면 물을 것이 없다. main에서 딴다로 바꿨다.
둘째, 금지 대상이 틀린 자리에 있었다. 로컬 main에 머지했다가 훅이 푸시를 막아 되돌리면서 알았다. 막아야 할 것은 PR을 어디로 여느냐가 아니라 PR 없이 머지하는 쪽이었다.
셋째, 이유가 하나가 아니었다. 내가 “품질 검토가 아니라 흐름 파악이 이유”라고 좁혔더니 정정이 왔다 — 둘 다라고. 그게 중요한 이유는 각각이 다른 안을 죽이기 때문이다. 품질만으로는 “커밋하고 amend” 안이 살아남고, 흐름까지 있어야 죽는다. 이유를 하나로 좁히면 6개월 뒤에 버린 안이 되살아난다.
마지막으로 적용 범위가 갈렸다. 이 저장소에서 브랜치와 PR을 실제로 돌려보니 내가 열고 내가 머지하는 빈 절차였다. 멈추는 것과 브랜치가 다른 이유로 있는 장치라 하나만 뗄 수 있다는 걸 여기서 알았다. 혼자 쓰는 기록 공간은 멈추는 것만 지키고, 배포본은 둘 다 지킨다.
정리
- 커밋 직전에 멈춘다. 커밋은 에이전트가 자기 일을 드러내야 하는 유일한 자리다
- 이유는 둘이다 — 품질 검토와 흐름 파악. 하나로 좁히면 “커밋하고
amend” 안이 되살아난다 git add도 하지 않는다.git diff하나로 전부 보여야 한다. 새로 만든 파일은 따로 표시한다- 커밋·푸시·PR을 각각 따로 요청받는다. 되돌리는 값이 단계마다 다르다
- 문서만으로는 안 지켜진다. 스킬은 로드될 때만 걸리므로 1단과 훅을 얹는다
- 훅은 통합 브랜치만 막는다. 뚫리지 않는 훅은 규칙이 아니라 고장이다
dev가 없으면main에서 딴다. 금지 대상은 PR 대상이 아니라 로컬 직머지다- 브랜치는 볼 사람이 있을 때만 판다. 멈추는 것과 다른 이유로 있는 장치라 하나만 뗄 수 있다
AI 코드 어시스턴트에 바로 적용하기
Claude Code — .claude/skills/commit-standby-standard/SKILL.md
---
name: commit-standby-standard
description: 작업 브랜치를 딴 뒤 커밋으로 넘어가지 않고 멈춰 리뷰를 받고, PR로 통합 브랜치에 올리는 절차. 코드를 고치기 시작할 때, 그리고 브랜치·커밋·푸시·PR을 다룰 때 반드시 적용한다.
---
# 커밋 대기 표준
고치는 것까지가 에이전트의 일이다. 커밋부터는 사람이 시작한다.
## 순서
1. 파일을 고치기 전에 통합 브랜치에서 작업 브랜치를 판다.
2. 요청받은 작업을 끝까지 끝낸다.
3. **커밋하지 않고 멈춘다.** 변경 요약을 내놓고 리뷰를 기다린다.
4. 커밋하라는 말을 들으면 그때 커밋한다.
5. 푸시와 PR은 커밋과 별개로 다시 요청받는다. PR은 브랜치를 딴 자리로 연다.
## 브랜치를 먼저 판다
- 통합 브랜치에서 파일을 고치지 않는다. **첫 파일을 열기 전에** 작업 브랜치를 판다.
- 따는 자리는 `dev`다. **`dev`가 없는 저장소면 `main`에서 딴다** — 그 저장소의 통합 브랜치가 하나뿐이라는 뜻이므로 물을 것이 없다. `dev`가 있는데 `main`에서 따지는 않는다.
- 이름은 `<타입>/<이슈번호>-<영문-케밥-슬러그>`로 짓는다.
- **타입은 그 프로젝트의 커밋 타입을 소문자로 내려 쓴다.** 커밋 규약이 없으면 `feat` `fix` `docs` `style` `refactor` `test` `chore`를 쓴다. `feature`·`bugfix`·`hotfix` 같은 변형을 섞지 않는다.
- **이슈(Jira·GitHub)가 있으면 그 번호를 넣는다** — `feat/PROJ-123-order-cancel-api`, `fix/142-null-user-id`.
- **이슈가 없으면 번호를 빼고** 요청받은 작업 내용으로 짓는다 — `feat/order-cancel-api`, `fix/null-user-id`.
- 이슈 번호를 지어내지 않는다. 확인되지 않으면 없는 것으로 본다.
- 이미 작업 브랜치 위에 있으면 새로 파지 않는다.
- 어느 자리에서 무슨 이름으로 팠는지 사용자에게 알린다.
## 통합 브랜치 직커밋은 훅이 막는다
- `.claude/hooks/commit-standby-guard.ps1`이 `Bash` PreToolUse 훅으로 걸려 있다. 통합 브랜치 위에서의 `git commit`·`git push`와, 통합 브랜치를 대상으로 지목한 `git push`를 exit 2로 막는다.
- 막혔으면 우회하지 않는다. 작업 브랜치를 파고 다시 한다. 이미 고친 파일은 `git checkout -b`로 그대로 따라온다.
- **작업 브랜치에서의 커밋은 훅이 막지 않는다.** 거기서 멈추는 건 이 문서의 규칙이지 훅의 일이 아니다 — "커밋해"라고 했을 때 뚫리지 않으면 안 되기 때문이다.
## 커밋 직전에 멈춘다
- 파일을 다 고친 직후에 멈춘다. 빌드와 테스트가 통과했더라도 멈춘다.
- `git add`도 하지 않는다. 스테이징하면 `git diff`가 비어 보인다. 작업 트리에 그대로 두어 명령 하나로 보이게 한다.
- "커밋해도 되겠습니까"만 묻고 넘어가지 않는다. 아래 요약을 먼저 내놓는다.
- 요약만 내놓고 멈춘다. 승인을 기다리는 동안 다음 작업을 시작하지 않는다.
## 대기할 때 내놓는 것
- 판 브랜치 이름과 딴 자리.
- 바꾼 파일 목록. **새로 만든 파일은 새로 만들었다고 표시한다** — 추적되지 않아 `git diff`에 안 잡힌다.
- 파일마다 무엇을 왜 바꿨는지 한 줄.
- 확인용 명령 (`git status`, `git diff`).
- 커밋 메시지 초안.
- 작업 중에 임의로 판단한 것과 확신이 없는 것.
## 리뷰 결과에 따라 하는 일
- **커밋하라고 하면** 커밋만 한다. 푸시와 PR로 이어가지 않는다.
- **더 고치라고 하면** 고치고 다시 대기한다. 아직 커밋하지 않았으므로 `--amend`도 `reset`도 필요 없다.
- **되돌리라고 하면** 무엇을 버리는지 파일 단위로 확인받은 뒤에 되돌린다.
- 한 번의 요청을 여러 커밋으로 쪼개지 않는다. 리뷰 단위가 곧 커밋 단위다.
## PR은 딴 자리로 되돌려 보낸다
- PR 대상은 브랜치를 딴 자리와 같다. `dev`에서 땄으면 `dev`로, `dev`가 없어 `main`에서 땄으면 `main`으로 연다.
- **`dev`가 있는데 `main`으로 PR을 열지 않는다.** 그리고 어느 경우든 작업 브랜치를 통합 브랜치에 **로컬에서 직접 머지하지 않는다** — 훅이 통합 브랜치 푸시를 막으므로 로컬 머지는 올라가지 못하고 히스토리만 갈린다. 머지는 PR에서 한다.
- 이슈 번호로 브랜치를 팠으면 PR 본문에서 그 이슈를 연결한다 (`Closes #142`).
- PR 본문에는 무엇을 왜 바꿨는지와 확인 방법을 적는다. 커밋 목록을 나열하는 것으로 대신하지 않는다.
- PR을 여는 것도 별도 요청이다. 커밋이나 푸시를 시켰다고 이어서 열지 않는다.
- 열린 PR을 머지하지 않는다. 머지는 사람이 한다.
## 하지 않는 것
- 사용자가 이번 요청에서 말하지 않은 단계로 넘어가지 않는다. 커밋을 시켰다고 푸시하지 않고, 푸시를 시켰다고 PR을 열지 않는다.
- 리뷰 전에 만든 커밋을 `git commit --amend`로 덮지 않는다.
- `git reset --hard`, `git checkout .`, `git clean`, force push를 확인 없이 실행하지 않는다.
- `--no-verify`로 커밋 훅을 건너뛰지 않는다.
- 리뷰 대기 중이라는 이유로 작업을 덜 끝내지 않는다. 요청받은 범위는 다 끝낸 상태로 멈춘다.
GitHub Copilot — .github/instructions/commit-standby-standard.instructions.md
---
description: 작업 브랜치를 딴 뒤 커밋으로 넘어가지 않고 멈춰 리뷰를 받고, PR로 통합 브랜치에 올리는 절차
applyTo: "**"
---
# 커밋 대기
- 통합 브랜치에서 파일을 고치지 않는다. 첫 파일을 열기 전에 `dev`에서 작업 브랜치를 판다.
- `dev`가 없는 저장소면 `main`에서 딴다. `dev`가 있는데 `main`에서 따지 않는다.
- 브랜치 이름은 `<타입>/<이슈번호>-<영문-케밥-슬러그>`로 짓는다.
- 타입은 그 프로젝트의 커밋 타입을 소문자로 내려 쓴다. 커밋 규약이 없으면 `feat` `fix` `docs` `style` `refactor` `test` `chore`를 쓴다. `feature`·`bugfix`·`hotfix` 같은 변형을 섞지 않는다.
- 이슈(Jira·GitHub)가 있으면 그 번호를 넣는다 (`feat/PROJ-123-order-cancel-api`, `fix/142-null-user-id`).
- 이슈가 없으면 번호를 빼고 요청받은 작업 내용으로 짓는다 (`feat/order-cancel-api`).
- 이슈 번호를 지어내지 않는다. 확인되지 않으면 없는 것으로 본다.
- 요청받은 작업을 끝까지 끝낸 뒤 **커밋하지 않고 멈춘다.** 빌드와 테스트가 통과했더라도 멈춘다.
- `git add`도 하지 않는다. 스테이징하면 `git diff`가 비어 보인다.
- 멈출 때 브랜치 이름과 딴 자리, 바꾼 파일 목록, 파일마다 무엇을 왜 바꿨는지, 확인용 명령, 커밋 메시지 초안을 함께 내놓는다.
- 새로 만든 파일은 새로 만들었다고 표시한다. 추적되지 않아 `git diff`에 잡히지 않는다.
- 임의로 판단한 것과 확신이 없는 것을 같이 적는다.
- 커밋하라는 말을 들으면 커밋만 한다. 푸시와 PR은 각각 따로 요청받는다.
- 더 고치라고 하면 고치고 다시 대기한다. 커밋 전이므로 `--amend`도 `reset`도 쓰지 않는다.
- 한 번의 요청을 여러 커밋으로 쪼개지 않는다. 리뷰 단위가 커밋 단위다.
- PR 대상은 브랜치를 딴 자리와 같다. `dev`가 있는데 `main`으로 PR을 열지 않는다.
- 작업 브랜치를 통합 브랜치에 로컬에서 직접 머지하지 않는다. 훅이 통합 브랜치 푸시를 막아 히스토리만 갈린다.
- 이슈 번호로 브랜치를 팠으면 PR 본문에서 그 이슈를 연결한다 (`Closes #142`).
- 열린 PR을 머지하지 않는다. 머지는 사람이 한다.
- `git reset --hard`, `git checkout .`, `git clean`, force push를 확인 없이 실행하지 않는다.
- `--no-verify`로 커밋 훅을 건너뛰지 않는다.
자신만의 철학을 만들어가는 중입니다.
댓글남기기