ureca-corp Git 업무 단위 분리 & PR 워크플로우
세션에서 발생한 모든 변경사항을 논리적 업무 단위로 나누고, 각 단위를 독립 브랜치로 커밋-푸시-PR까지 자동 처리하는 워크플로우.
단계 1: 변경사항 전체 파악
git status
git diff --stat HEAD
git diff HEAD
- 미추적(untracked), 수정(modified), 스테이징된 파일 모두 확인
- 삭제된 파일도 포함하여 전체 변경 범위를 파악
- 현재 브랜치와 원격 브랜치 상태도 확인:
git branch -vv
단계 2: 업무 단위 분류
변경된 파일들을 논리적 작업 단위로 그룹화한다. 파일 경로, 수정 내용, 관련성을 기준으로 판단:
분류 기준 (우선순위 순):
- 기능 단위 — 같은 기능/도메인에 속하는 파일들 (예: auth 관련 파일들)
- 변경 유형 — feat(기능 추가), fix(버그 수정), refactor(리팩토링), docs(문서), chore(설정)
- 독립성 — 서로 영향 없이 배포 가능한 단위
분류 후 사용자에게 반드시 확인:
발견된 업무 단위:
1. [유형] 설명 — 파일 목록
2. [유형] 설명 — 파일 목록
...
이 분류로 진행할까요? 수정이 필요하면 말씀해주세요.
사용자 확인 없이 다음 단계로 진행하지 말 것.
단계 3: 현재 브랜치 및 기반 브랜치 확인
git remote show origin | grep "HEAD branch"
git branch -r | grep -E "main|master"
기반 브랜치 결정 (보통 main 또는 master). 각 작업 단위 브랜치는 이 기반 브랜치에서 분기한다.
현재 브랜치에 미커밋 변경사항이 있으므로, 임시로 stash하거나 작업 순서를 조율:
git stash # 필요 시
단계 4: 각 업무 단위 처리 (순서대로 반복)
각 업무 단위에 대해 아래 절차를 완전히 수행한 후 다음 단위로 넘어간다.
4-1. 브랜치 생성
기반 브랜치에서 새 브랜치 생성:
git checkout <기반브랜치>
git pull origin <기반브랜치>
git checkout -b <브랜치명>
브랜치 명명 규칙:
- 형식:
<유형>/<짧은-설명-영문> - 예:
feat/user-authentication,fix/login-redirect-bug,refactor/api-client - 소문자, 하이픈 사용, 30자 이내
4-2. 해당 파일만 스테이징
해당 업무 단위에 속하는 파일만 정확히 추가:
git add <파일1> <파일2> ...
# 신규 파일도 포함
# 삭제된 파일은 git rm 또는 git add -u
스테이징 상태 확인: git status
4-3. 한글 커밋 메시지 생성
커밋 메시지 구조:
<유형>: <한글 TLDR — 이 커밋으로 무엇이 달라지는지 한 줄로>
- <변경 내용 1>
- <변경 내용 2>
- <변경 내용 3>
제목 규칙 (첫 줄):
- 반드시 한 줄로 끝낼 것 — 줄바꿈 없이 TLDR 요약
- "무엇을 했다"가 아니라 "무엇이 가능해졌다/해결됐다" 관점으로 작성
- 50자 이내 권장
본문 규칙 (리스트):
- 기술 용어 대신 기능·사용자 관점 용어 사용
- ❌
AuthService 리팩토링,JWT 미들웨어 추가 - ✅
로그인 유지 방식 개선,자동 로그아웃 기능 추가
- ❌
- 변경사항이 많지 않으면 3개 내외, 최대 5개를 넘지 않을 것
- 비개발자가 읽어도 "아, 이게 바뀌었구나" 알 수 있을 정도의 간결함
유형 분류:
| 유형 | 의미 |
|---|---|
feat |
새 기능 추가 |
fix |
버그 수정 |
refactor |
내부 구조 개선 (기능 변화 없음) |
docs |
문서 수정 |
test |
테스트 추가/수정 |
chore |
빌드, 설정, 패키지 등 |
style |
화면 스타일, 포맷 변경 |
perf |
속도·성능 개선 |
예시:
feat: 소셜 계정으로 로그인할 수 있는 기능 추가
- 구글, 카카오 계정으로 로그인 가능
- 기존 이메일 계정과 소셜 계정 연동 지원
- 로그인 화면에 소셜 로그인 버튼 추가
fix: 로그인 후 이전 페이지로 돌아가지 않던 문제 수정
- 로그인 완료 시 원래 보던 페이지로 자동 이동
- 세션 만료 후 재로그인해도 동일하게 동작
chore: 배포 환경 설정 파일 정리
- 개발/운영 환경 설정 분리
- 불필요한 테스트용 값 제거
커밋 실행:
git commit -m "$(cat <<'EOF'
<유형>: <한글 TLDR>
- <변경 내용 1>
- <변경 내용 2>
- <변경 내용 3>
EOF
)"
4-4. 푸시
git push -u origin <브랜치명>
4-5. PR 생성
gh pr create \
--title "<유형>: <한글 제목>" \
--base <기반브랜치> \
--body "$(cat <<'EOF'
## 변경 요약
<!-- 이 PR에서 무엇을 변경했는지 -->
## 변경 이유
<!-- 왜 이 변경이 필요했는지 -->
## 주요 변경 파일
<!-- 변경된 주요 파일 목록 -->
## 테스트 방법
<!-- 변경사항을 확인하는 방법 -->
EOF
)"
PR URL을 기록해두고 사용자에게 표시한다.
단계 5: 전체 PR 목록 요약
모든 업무 단위 처리 후:
gh pr list --author "@me" --state open
생성된 PR 목록을 표 형태로 정리하여 사용자에게 제공:
생성된 PR 목록:
| # | 브랜치 | 제목 | URL |
|---|--------|------|-----|
| 1 | feat/... | feat: ... | https://... |
| 2 | fix/... | fix: ... | https://... |
단계 6: PR 리뷰 모니터링 (리뷰 항목이 있는 경우)
PR에 리뷰어가 지정되어 있거나 리뷰 요청이 있는 경우에만 수행.
리뷰 상태 확인
gh pr list --author "@me" --state open --json number,title,reviewDecision,reviews
리뷰가 없거나 모두 승인(APPROVED)이면 모니터링 불필요. 리뷰 대기/변경 요청 상태면 /loop 스킬을 사용하여 모니터링.
모니터링 루프 설정
/loop 스킬을 사용하여 1분마다 PR 상태 확인:
각 PR에 대해 아래 명령으로 상태 추적:
gh pr checks <PR번호> && gh pr view <PR번호> --json reviewDecision,reviews,statusCheckRollup
모니터링 종료 조건:
- 모든 PR이
APPROVED상태 - CI/CD 체크가 모두 통과 (
✓) - 머지가 완료된 경우
이상 감지 시:
- 리뷰에서
CHANGES_REQUESTED— 요청된 변경사항 목록을 사용자에게 전달 - CI 체크 실패 — 실패한 체크와 오류 내용을 요약하여 보고
- 모든 PR 상태가 이상 없음을 최종 확인한 후 완료 보고
최종 확인 보고 형식
PR 모니터링 완료
| PR | 제목 | 리뷰 | CI | 상태 |
|----|------|------|----|------|
| #1 | feat: ... | 승인됨 | 통과 | 이상 없음 |
| #2 | fix: ... | 승인됨 | 통과 | 이상 없음 |
모든 PR 이상 없음 확인 완료.
주의사항
- stash 관리: 작업 시작 전 stash한 경우, 모든 단위 처리 후
git stash pop으로 복원 - 충돌 방지: 각 브랜치는 기반 브랜치(main)에서 분기하므로 서로 충돌 없음
- 파일 누락 방지: 각 단위의 파일 목록을 스테이징 전후
git status로 반드시 확인 - 커밋 전 검증:
git diff --staged로 스테이징된 내용이 의도한 것인지 확인 - 원격 브랜치 확인: push 전 동일 브랜치명이 원격에 없는지 확인