| name | commit-all-changes |
| description | 변경사항을 맥락(수정 목적)과 종류별로 그룹 지어 그룹마다 별도 커밋. 폴더보다 "어떤 맥락에서 수정되었는지" 우선. hooks 수정 시 제목에 훅명, 본문에 수정 이유 명시. 규칙은 rules/git-commit-message.mdc 참고. |
Commit All Changes (분할 커밋)
변경사항을 **맥락(수정 목적)**과 **종류(TYPE)**에 따라 그룹 짓고, 그룹마다 하나의 커밋을 만든다. 폴더가 아닌 “어떤 맥락에서 수정되었는지”를 기준으로 묶는다. 한 번에 git add -A 후 단일 커밋하지 않는다.
그룹 분류 기준
1) 종류별 = 맥락(수정 목적) 우선
어떤 폴더의 파일이 수정되었는지보다, “어떤 맥락에서 / 왜” 수정되었는지가 더 중요하다.
같은 폴더라도 수정 맥락이 다르면 다른 그룹(다른 커밋)으로 나눈다. 반대로 다른 폴더 파일이라도 같은 맥락이면 한 그룹으로 묶을 수 있다.
- 그룹의 기준: 이 변경이 이루어진 목적·맥락 (예: “A 컴포넌트 폴더 구조 리팩터”, “B 기능을 위한 훅 수정”, “C 페이지 버그 수정”).
- 경로(도메인/폴더)는 참고용으로만 쓴다. 경로가 같아도 맥락이 다르면 그룹을 나눈다.
| 맥락 예시 | 설명 |
|---|
| 특정 컴포넌트 리팩터 | better-link, range-calendar-button 등 “이 컴포넌트를 폴더 구조로 분리”한 맥락 |
| 특정 도메인 반영 | customers/orders 등 “이 도메인 페이지·로딩에 위 변경 반영”한 맥락 |
| 공통 레이어 수정 | 레이아웃, 공통 훅 등 “여러 곳에 쓰이는 레이어만” 수정한 맥락 |
2) TYPE (커밋 종류)
각 그룹의 변경 성격에 맞는 TYPE을 붙인다.
- FEAT: 새 기능 추가
- FIX: 버그 수정
- REFACTOR: 구조·패턴 변경 (동작 동일)
- CHORE: 빌드, 설정, 정리, 문서 등
- SAVE: 작업 중간 저장(WIP)
한 그룹 안에 FEAT와 REFACTOR가 섞이면, 주된 맥락에 맞는 TYPE 하나를 쓰거나, 맥락을 나눠서 그룹을 나눈다.
워크플로우
-
규칙 확인
./git-commit-message.md를 읽고 형식과 TYPE을 적용한다.
-
변경사항 파악
git status로 변경/추가/삭제된 파일 목록을 확인한다.- 필요하면
git diff --stat 또는 git diff로 각 파일의 변경 성격을 파악한다.
-
그룹 분류
- **맥락(수정 목적)**을 기준으로 파일을 그룹으로 나눈다. 폴더가 같아도 맥락이 다르면 다른 그룹으로 둔다.
- 그룹별로 TYPE과
[TYPE] 제목 초안을 정한다.
- 그룹 목록을 사용자에게 간단히 보여주고, “다음 그룹들로 커밋할 예정”이라고 안내해도 된다.
-
그룹별 스테이징 및 커밋
- 한 그룹씩 다음을 반복한다:
- 해당 그룹에 속한 파일만 스테이징:
git add <path1> <path2> ...
- 메시지 작성:
[TYPE] 제목 (해당 그룹의 맥락·목적에 맞게).
- hooks 그룹인 경우: 제목에 수정된 훅 이름을 명시하고, 본문에 왜 수정했는지 작성한 뒤
git commit -m "[TYPE] 제목" -m "본문" 으로 커밋한다.
- 그 외:
git commit -m "[TYPE] 제목"
- 다음 그룹으로 넘어가서 반복한다.
git add -A로 한 번에 스테이징하지 않는다.
-
마무리
- 모든 그룹을 커밋한 뒤
git status로 남은 변경이 없는지 확인한다.
- 남은 변경이 있으면 “기타” 그룹으로 분류하거나, 필요 시 추가 그룹을 정해 같은 방식으로 커밋한다.
참고
- 그룹이 하나뿐이면 그룹 하나만 커밋하면 된다.
- 분류가 애매한 파일은 같은 맥락으로 보이는 그룹에 넣거나, “기타/정리” 같은 소규모 그룹으로 묶어 한 번에 커밋해도 된다.
- 삭제된 파일은 그 삭제가 속한 맥락의 그룹에 포함해 함께 스테이징·커밋한다 (예:
pagination 삭제 → “data-table/페이징 관련 수정” 그룹).
