Git 워크플로우 자동화은(는) 무엇을 하나요?
기능 개발 수명 주기 전반에 걸친 완전한 Git 워크플로우 자동화: 브랜치 생성부터 병합까지.
개요
이 스킬은 기능 개발 워크플로우를 완전히 자동화합니다:
- 기능 브랜치 생성 — 기본 브랜치에서
- 변경 사항 커밋 — 이모지 컨벤셔널 커밋 사용
- 원격 저장소에 푸시
- PR 생성 — 구조화된 마크다운 템플릿 사용
- 리뷰 폴링 — 코드 리뷰 댓글 대기
- 평가 및 수정 — 각 댓글을 분류하고 수정
- 수정 사항 푸시 및 응답 — 변경 사항 푸시, 모든 댓글에 응답
- 반복 — 수정 사항에 대한 새로운 피드백 재확인
- 상태 모니터링 (UNSTABLE -> CLEAN)
- PR 병합 (스쿼시 + 브랜치 삭제)
- 정리 — 로컬 및 원격 브랜치 정리
⚠️ 필수: 전체 워크플로우 실행 시, 모든 11단계가 순차적으로 실행되어야 합니다. PR 생성(4단계) 후 중단하지 마십시오. 5-11단계(리뷰, 수정, 병합, 정리)는 선택적 후속 작업이 아닌 워크플로우의 필수 부분입니다. 각 단계에서 중단 없이 다음 단계로 계속 진행하세요.
스킬 트리거
자연어를 사용하여 워크플로우의 모든 부분을 호출할 수 있습니다:
전체 워크플로우
- "feature X에 대한 전체 Git 워크플로우를 실행해줘"
- "기능 브랜치 생성, 커밋, PR 생성 및 병합까지 해줘"
- "전체 PR 사이클 실행"
개별 단계
- "X에 대한 기능 브랜치를 생성해줘"
- "내 변경 사항을 이모지 컨벤셔널 커밋으로 커밋해줘"
- "구조화된 템플릿으로 PR을 생성해줘"
- "내 PR 상태를 모니터링해줘"
- "PR을 병합하고 정리해줘"
리뷰 처리
- "PR 댓글을 확인하고 처리해줘"
- "PR #123의 리뷰 댓글을 수정해줘"
- "현재 PR의 피드백을 처리해줘"
1단계: 기능 브랜치 생성
# 기본 브랜치 감지 (main, master 등)
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | sed 's/.*: //' || echo "main")
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git checkout -b feat/descriptive-name
브랜치 명명 규칙:
feat/— 새로운 기능fix/— 버그 수정docs/— 문서 변경refactor/— 코드 리팩토링perf/— 성능 개선test/— 테스트 추가/변경chore/— 유지 보수 작업ci/— CI/CD 변경
2단계: 이모지 컨벤셔널 커밋으로 커밋
스테이징 및 커밋
git add <files>
git commit -m "<emoji> <type>[optional scope]: <description>"
커밋 유형 및 이모지
| 유형 | 이모지 | 설명 | 예시 |
|---|---|---|---|
feat | ✨ | 새로운 기능 | ✨ feat(auth): add JWT token validation |
fix | 🐛 | 버그 수정 | 🐛 fix(api): resolve memory leak in handler |
docs | 📝 | 문서 | 📝 docs: update API endpoints documentation |
style | 🎨 | 코드 스타일 | 🎨 style: format code with prettier |
refactor | ♻️ | 코드 리팩토링 | ♻️ refactor: simplify authentication logic |
perf | ⚡️ | 성능 | ⚡️ perf: optimize database query performance |
test | ✅ | 테스트 | ✅ test: add unit tests for user service |
chore | 🔧 | 유지 보수 | 🔧 chore: update build dependencies |
ci | 👷 | CI/CD | 👷 ci: add github actions workflow |
build | 📦 | 빌드 시스템 | 📦 build: upgrade to webpack 5 |
revert | ⏪ | 되돌리기 | ⏪ revert: rollback payment integration |
커밋 메시지 형식
간단 (기본):
✨ feat(auth): add JWT token validation
전체 (본문 포함):
✨ feat(auth): add JWT token validation
Implement JWT token validation middleware that:
- Validates token signature and expiration
- Extracts user claims from payload
- Adds user context to request object
This improves security by ensuring all protected routes
validate authentication tokens properly.
Co-authored-by: Claude <[email protected]>
모범 사례
- ✅ 현재 시제, 명령형 사용 ("added"가 아닌 "add")
- ✅ 첫 번째 줄은 50자 미만 유지 (최대 72자)
- ✅ 첫 글자 대문자
- ✅ 제목 줄 끝에 마침표 생략
- ✅ 컨텍스트를 위해 범위 사용 (예:
feat(auth):) - ✅ AI 지원 커밋의 경우
Co-authored-by:바닥글 포함
3단계: 원격 저장소에 푸시
git push -u origin feat/descriptive-name
4단계: 구조화된 템플릿으로 PR 생성
PR 생성 전, 실제 변경 사항 분석:
# 기본 브랜치 대비 이 브랜치의 모든 변경 사항 확인
git diff "$DEFAULT_BRANCH"...HEAD
# 커밋 메시지 확인
git log "$DEFAULT_BRANCH"..HEAD --pretty=format:"%s"
반드시 실제 diff에서 PR 제목과 본문을 생성해야 합니다. — 절대 플레이스홀더 텍스트를 사용하지 마십시오.
- 제목: 기본 커밋의 이모지와 유형 사용 (예:
✨ feat:,🐛 fix:). 이모지를 포함하세요. - 본문: 모든 섹션을 diff에서 추출한 실제 내용으로 채우세요.
[One-line summary]또는[First change]를 작성하지 말고 — 실제 변경 사항에 대한 실제 설명을 작성하세요.
gh pr create \
--title "<EMOJI> <TYPE>: <brief description>" \
--body "$(cat <<EOF
## 📝 요약
[diff를 기반으로 한 실제 한 문장 요약을 작성]
## 🔄 변경 사항
[의미 있는 각 변경 사항을 이모지 접두사와 함께 항목으로 나열. git diff 출력 기반]
## ✅ 검증 방법
[실제 변경된 내용에 기반한 구체적이고 실행 가능한 검증 단계를 제공]
## 🔗 참고 자료
[관련 링크 포함: 이슈 참조(Closes #N), 문서, 관련 PR. 없으면 섹션 생략]
---
🤖 [Claude Code](https://claude.com/claude-code)로 생성됨
EOF
)"
PR 템플릿 예시
기능 PR:
## 📝 요약
Google 및 GitHub 제공자를 지원하는 OAuth2 인증 흐름을 추가합니다.
## 🔄 변경 사항
- ✨ PKCE와 함께 OAuth2 인증 코드 흐름 추가
- 🔐 암호화된 쿠키로 안전한 토큰 저장 구현
- 📝 첫 로그인 시 사용자 프로필 동기화 추가
- 🎨 제공자 버튼으로 로그인 UI 업데이트
## ✅ 검증 방법
1. 로컬에서 실행: `npm run dev`
2. `/login` 방문 후 "Google로 로그인" 클릭
3. OAuth 흐름 완료
4. 사용자 프로필이 올바르게 생성되었는지 확인
5. 페이지 새로고침 시 토큰 갱신이 작동하는지 확인
```bash
# 테스트 스위트
npm run test:auth
🔗 참고 자료
- Closes #456
- OAuth 2.1 RFC: https://datatracker.ietf.org/doc/html/rfc6749
- 설계 문서: docs/design/oauth2-integration.md
**버그 수정 PR:**
```markdown
## 📝 요약
시간이 지남에 따라 메모리 사용량을 증가시키는 이벤트 핸들러의 메모리 누수를 수정합니다.
## 🔄 변경 사항
- 🐛 이벤트 리스너가 제대로 제거되지 않는 문제 수정
- ✅ componentWillUnmount에 정리 코드 추가
- 📝 이벤트 핸들러 생명 주기에 대한 문서 추가
## ✅ 검증 방법
1. 브라우저 DevTools → Memory 열기
2. 힙 스냅샷 생성
3. 앱을 10번 탐색
4. 다른 스냅샷 생성
5. 분리된 DOM 노드가 없는지 확인
## 🔗 참고 자료
- Fixes #789
- 관련 이슈: #123
5단계: 코드 리뷰 폴링
댓글을 확인하기 전에 코드 리뷰가 완료될 때까지 기다립니다:
echo "⏳ 코드 리뷰를 기다리는 중..."
sleep 180
리뷰 댓글 가져오기
# 저장소 슬러그 확인
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
# PR 목록 확인
gh pr list
# PR 세부 정보 확인
gh pr view <PR_NUMBER>
# 코드 수준의 인라인 리뷰 댓글 가져오기 (답글 제외하고 원본만 필터링)
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | {id: .id, path: .path, line: .line, body: .body}'
# 이슈 수준 댓글 가져오기 (일반 PR 댓글)
gh api repos/$REPO_SLUG/issues/$PR_NUMBER/comments --jq '.[] | {id: .id, body: .body}'
# 리뷰 상태 확인
gh pr view $PR_NUMBER --json reviews --jq '.reviews[] | {state: .state, body: .body, author: .author.login}'
6단계: 리뷰 댓글 평가 및 수정
각 댓글 분류
| 카테고리 | 조치 | 예시 |
|---|---|---|
| 반드시 수정 | 코드 변경 필요 | 버그, 보안 문제, 논리 오류, 깨진 테스트 |
| 수정 권장 | 코드 변경 권장 | 코드 스타일, 명명, 누락된 오류 처리 |
| 제안 | 선택 사항, 판단 적용 | 대체 접근 방식, 더 나은 패턴 |
| 질문 | 응답만, 코드 변경 불필요 | 검토자가 명확성을 요청하는 경우 |
| 이미 해결됨 | 응답만 | 이미 수정된 코드를 참조하는 댓글 |
각 댓글에 대한 처리
- 지정된 줄 번호에서 참조된 파일 읽기
- 피드백을 해결하는 데 필요한 최소 수정 적용
- 적절한 이모지 커밋으로 스테이징 및 커밋
- 나중에 응답하기 위해 댓글 ID 추적
# 수정 적용
# ... 코드 변경 ...
# 수정 커밋
git add <changed-files>
git commit -m "🐛 fix: review feedback - handle edge case"
7단계: 수정 사항 푸시 및 모든 댓글에 응답
모든 수정 사항이 커밋된 후:
# 모든 수정 커밋 푸시
git push
응답하기 전에 수정 해시를 계산합니다:
FIX_HASH=$(git rev-parse --short HEAD)
그런 다음 각 댓글에 대해 셸 변수 $FIX_HASH와 5단계의 가져오기에서 얻은 리터럴 숫자 id를 사용하여 응답합니다:
# 인라인 리뷰 댓글에 응답
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments \
--method POST \
--field body="✅ $FIX_HASH에서 수정됨. <실제 변경 사항 설명>" \
--field in_reply_to=$COMMENT_ID
# 일반 PR 댓글에 응답 (참고: GitHub API는 스레드형 답글이 아닌 새 최상위 댓글을 생성합니다 — 이는 API 제한사항입니다)
gh api repos/$REPO_SLUG/issues/$PR_NUMBER/comments \
--method POST \
--field body="✅ $FIX_HASH에서 처리됨. <실제 변경 사항 설명>"
응답 형식:
- 수정:
✅ <short_hash>에서 수정됨 — <변경 사항> - 질문:
💡 <답변> - 적용되지 않은 제안:
🙏 좋은 제안이지만, <이유>. 필요하면 다시 논의하겠습니다.
8단계: 반복 — 새 피드백 재확인
수정 사항 푸시 후:
# 댓글을 다시 가져와 이미 처리된 ID와 비교
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | .id'
- 새 댓글 ID 발견 → 6단계부터 반복
- 새 댓글 없음 → 9단계로 진행
일반적인 리뷰 응답
| 댓글 유형 | 응답 접근 방식 |
|---|---|
| 코드 스타일 | 수정 + 🎨 style: 커밋 |
| 버그 리포트 | 수정 + 🐛 fix: 커밋 |
| 테스트 누락 | 테스트 추가 + ✅ test: 커밋 |
| 문서화 | 문서 업데이트 + 📝 docs: 커밋 |
| 성능 | 최적화 + ⚡️ perf: 커밋 |
| 리팩토링 | 리팩토링 + ♻️ refactor: 커밋 |
9단계: PR 상태 모니터링 (UNSTABLE -> CLEAN)
이 모니터링 루프를 사용하여 모든 CI 검사가 통과할 때까지 기다립니다:
#!/bin/bash
PR_NUMBER="<PR_NUMBER>"
for i in {1..60}; do
pr_status=$(gh pr view $PR_NUMBER --json mergeStateStatus --jq '.mergeStateStatus')
if [ "$pr_status" = "CLEAN" ]; then
echo "✅ 모든 검사 통과! 병합 준비 완료."
exit 0
fi
echo "⏳ 대기 중... ($i/60) - 상태: $pr_status"
sleep 10
done
echo "❌ 시간 초과 - 10분 내에 검사가 통과하지 않았습니다."
exit 1
가능한 상태:
UNKNOWN— 상태가 아직 결정되지 않음BEHIND— 브랜치가 기본 브랜치보다 뒤쳐짐BLOCKED— 실패한 검사로 차단됨DIRTY— 병합 충돌DRAFT— PR이 초안 상태임UNSTABLE— 검사가 아직 통과하지 않음CLEAN— 모든 검사 통과, 병합 준비 완료
10단계: PR 병합 (스쿼시 + 브랜치 삭제)
gh pr merge <PR_NUMBER> --squash --delete-branch
참고: --subject를 생략하면 GitHub가 PR 제목을 기본값으로 사용하며, 여기에는 이미 올바른 이모지/유형 접두사가 포함되어 있습니다.
병합 옵션:
--squash— 모든 커밋을 하나로 결합 (권장)--merge— 전체 커밋 기록 유지하며 병합--rebase— 기본 브랜치 위에 커밋 리베이스--delete-branch— 병합 후 브랜치 삭제
11단계: 로컬 및 원격 브랜치 정리
# 기본 브랜치로 전환
git checkout "$DEFAULT_BRANCH"
# 최신 변경 사항 가져오기
git pull origin "$DEFAULT_BRANCH"
# 로컬 브랜치 삭제
git branch -d feat/descriptive-name
# 필요한 경우 강제 삭제
git branch -D feat/descriptive-name
# 원격 브랜치 삭제 (아직 삭제되지 않은 경우)
git push origin --delete feat/descriptive-name
전체 워크플로우 스크립트
다음은 전체 워크플로우를 결합한 완전한 스크립트입니다 (모니터링, 수정, 병합, 정리):
#!/bin/bash
set -e
PR_NUMBER="<PR_NUMBER>"
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
# 5단계: 리뷰 대기
echo "⏳ 코드 리뷰를 위해 120초 대기 중..."
sleep 180
# 6-8단계: 수정 루프 (최대 5회 반복)
PROCESSED_IDS=""
MAX_ITERATIONS=5
iteration=0
while [ $iteration -lt $MAX_ITERATIONS ]; do
iteration=$((iteration + 1))
COMMENT_IDS=$(gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | .id')
NEW_IDS=$(comm -23 <(echo "$COMMENT_IDS" | sort) <(echo "$PROCESSED_IDS" | sort) || true)
if [ -z "$NEW_IDS" ]; then
echo "✅ 새 리뷰 댓글이 없습니다."
break
fi
echo "📝 새 리뷰 댓글을 찾았습니다. 처리 중..."
# (Claude Code가 여기서 각 댓글을 평가하고 수정합니다)
git push
PROCESSED_IDS="${PROCESSED_IDS}
${NEW_IDS}"
echo "⏳ CI 및 재검토 대기 중..."
sleep 60
done
if [ $iteration -ge $MAX_ITERATIONS ]; then
echo "⚠️ 최대 수정 반복 횟수에 도달했습니다. 수동 검토가 필요할 수 있습니다."
fi
# 9단계: PR 상태 모니터링
echo "🔍 PR #$PR_NUMBER 상태 모니터링 중..."
HEAD_BRANCH=$(gh pr view $PR_NUMBER --json headRefName --jq '.headRefName')
for i in {1..60}; do
pr_status=$(gh pr view $PR_NUMBER --json mergeStateStatus --jq '.mergeStateStatus')
if [ "$pr_status" = "CLEAN" ]; then
echo "✅ 모든 검사 통과!"
break
fi
echo "⏳ 대기 중... ($i/60) - 상태: $pr_status"
sleep 10
done
# 10단계: PR 병합
echo "🔀 PR #$PR_NUMBER 병합 중..."
gh pr merge $PR_NUMBER --squash --delete-branch
# 11단계: 정리
echo "🧹 정리 중..."
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git branch -D "$HEAD_BRANCH" 2>/dev/null || true
echo "✅ 완료! 다음 기능 준비 완료."
빠른 참조 명령어
브랜치 작업
git checkout -b feat/feature-name # 기능 브랜치 생성
git checkout "$DEFAULT_BRANCH" && git pull # 기본 브랜치와 동기화
git branch -d feat/feature-name # 로컬 브랜치 삭제
git branch -D feat/feature-name # 로컬 브랜치 강제 삭제
git push origin --delete feat/feature-name # 원격 브랜치 삭제
PR 작업
gh pr create --title "<제목>" --body "<본문>" # PR 생성
gh pr view <PR_NUMBER> # PR 세부 정보 확인
gh pr list # PR 목록 확인
gh pr merge <PR_NUMBER> --squash --delete-branch # PR 병합
리뷰 댓글
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments # 인라인 댓글 가져오기
gh api repos/$REPO_SLUG/issues/$PR_NUMBER/comments # 일반 댓글 가져오기
검사 상태
gh pr view <PR_NUMBER> --json mergeStateStatus --jq '.mergeStateStatus' # 병합 상태 확인
gh pr view <PR_NUMBER> --json statusCheckRollup --jq '.statusCheckRollup' # 개별 검사 확인
사용자 정의 안내
환경 변수
필요한 환경 변수:
GITHUB_TOKEN— GitHub CLI (gh) 인증에 사용
스킬 구성
이 스킬은 다음 명령을 사용할 수 있는 환경이 필요합니다:
git— Git 버전 관리gh— GitHub CLI (2.0 이상 권장)bash— 셸 스크립트 실행
리뷰 폴링 지연 시간을 조정하려면 5단계 스크립트에서 sleep 값을 조정합니다.