Git 브랜치 작업
모든 변경 사항은 별도의 브랜치에서 작업합니다. 여기에는 한 줄짜리 수정이나 이슈가 없는 변경도 포함됩니다. 기본 브랜치에 커밋하지 마세요.
1. 기본 브랜치 찾기
다음 순서로 답을 제공하는 첫 번째 출처를 사용하세요:
- 저장소 지침.
CLAUDE.md,CONTRIBUTING.md및.github/문서를 읽습니다. 기본 브랜치나 통합 브랜치가 명시되어 있으면 그 브랜치를 사용하세요. - 원격 기본 브랜치.
git symbolic-ref --short refs/remotes/origin/HEAD # origin/<이름> 출력 gh repo view --json defaultBranchRef -q .defaultBranchRef.name - 모호한 경우. 원격에
develop이나development브랜치도 있고 어떤 문서도 기본 브랜치를 명시하지 않으면 사용자에게 물어보세요. 추측하지 마세요.
통합 브랜치(예: develop)가 기본 브랜치일 때, 릴리스된 버전에 대한 핫픽스는 기본 브랜치에서 시작합니다. 사용자가 작업을 핫픽스라고 부를 때만 사용하세요.
2. 현재 위치 확인
git status --porcelain
git rev-parse --abbrev-ref HEAD
- 작업 트리에 사용자가 하지 않은 변경 사항이 있으면 중단하고 사용자에게 처리 방법을 물어보세요.
- 이미 이 작업을 위한 브랜치에 있다면 그 브랜치에 계속 머무르세요.
- 기본 브랜치에 자신의 커밋되지 않은 편집 내용이 있다면 이동하세요:
git switch -c <이름>명령어가 작업 트리에 변경 사항을 유지합니다.
3. 원격 최신 커밋에서 브랜치 시작
git fetch origin --prune
git switch -c <이름> origin/<기본>
git log -1 --oneline
origin/<기본>에서 시작하면 로컬 기본 브랜치가 오래되어도 문제가 없습니다. 기본 브랜치에서 git pull을 먼저 실행하여 "따라잡을" 필요가 없습니다.
4. 브랜치 이름 짓기
저장소 규칙이 있다면 그 규칙을 따르세요. 없다면 <타입>/<참조>-<슬러그> 형식을 사용하세요:
| 부분 | 값 |
|---|---|
타입 | feat, fix, docs, chore, refactor, test, release, hotfix |
참조 | 이슈 번호(42), 파이프라인 티켓(ticket-007), 또는 생략 |
슬러그 | 두 단어에서 다섯 단어 사이, 소문자, 하이픈으로 연결 |
예시: fix/42-null-session-crash, feat/ticket-007-search-filters, docs/readme-install-steps.
5. 작업 중
- 각각 의미 있는 작은 단위로 커밋하세요. 제목은 명령형으로 72자 이내로 작성하고, 본문에는 이유를 설명하세요.
- 커밋 메시지에
Co-Authored-By: Claude트레일러를 추가하지 마세요. 이는 gener8v 규칙입니다. - 첫 번째 푸시 전에는
origin/<기본>으로 리베이스할 수 있습니다. 브랜치가 푸시된 후에는 대신 기본 브랜치를 병합하세요. 푸시된 브랜치를 리베이스하면 히스토리를 다시 쓰게 되며,engineering:git-safety가 이를 제어합니다. - 첫 번째 실패 시 중단되는 체인으로 푸시하세요:
set -o pipefail git fetch origin && <테스트 명령어> 2>&1 | tail -n 40 && git push -u origin HEADset -o pipefail없이| tail을 사용하면 이전 명령어의 종료 코드가 숨겨집니다. Git 명령어나 테스트 명령어를tail로 파이프할 때는 반드시set -o pipefail을 함께 사용하세요.
병렬 작업
동시에 코드를 편집하는 둘 이상의 에이전트가 있는 경우, 에이전트를 시작하기 전에 resources/parallel-work.md 문서를 읽으세요. 요약하면: 기본 브랜치에서 하나의 배치 브랜치를 만들고, 배치 브랜치에서 각 에이전트당 하나의 작업 트리와 브랜치를 생성하며, 두 에이전트가 동일한 파일에서 작업하지 않도록 합니다.
완료 조건
- 명확한 이름의 브랜치에 있으며, 현재
origin/<기본>에서 시작되었습니다. git status에 다른 사람의 변경 사항이 표시되지 않습니다.
관련 스킬
engineering:github-pr-merge: 작업 완료 시 PR을 엽니다.engineering:git-safety: 강제 푸시, 브랜치 삭제 등 위험한 명령어에 대한 승인 규칙을 제공합니다.engineering:github-issue-workflow: 이슈 또는 파이프라인 티켓의 전체 라이프사이클을 관리합니다. 이 스킬을 가장 먼저 호출합니다.