1. 문제 상황
1.1 발생한 문제
GitHub에 push 된 커밋 히스토리를 확인하던 중,
Conventional Commit 규칙에 맞지 않는 커밋 메시지가 포함된 것을 발견했습니다.

1.2 환경 정보
Git 환경
- Repository: 개인 프로젝트
- Branch:
main - 원격 저장소: GitHub (
origin/main) - 상태: 로컬 브랜치와 원격 브랜치 동기화됨
main → origin/main문제 커밋 위치
- 가장 오래된 커밋 (히스토리 하단)
- 이미 원격 저장소에 push 완료된 상태
2. 해결 방법 (Interactive Rebase)
2.1 Interactive Rebase란?
Interactive Rebase는
과거 커밋의 순서, 내용, 메시지를 수정할 수 있는 Git 기능입니다.
주요 특징
- 과거 커밋 메시지 수정 가능
- 커밋 히스토리 재작성
- 이미 push된 커밋의 경우 force push 필요
2.2 해결 절차
1. 수정할 커밋 범위 지정
최근 커밋이 3개이므로 다음 명령 실행
git rebase -i HEAD~32. rebase 편집 화면 수정
pick a1b2c3 feat: 게시글 CRUD 기능 구현
pick d4e5f6 chore: JPA 및 MySQL 의존성 추가
pick g7h8i9 featL snowflake 추가featL 커밋을 수정 대상으로 변경
pick a1b2c3 feat: 게시글 CRUD 기능 구현
pick d4e5f6 chore: JPA 및 MySQL 의존성 추가
reword g7h8i9 featL snowflake 추가3. 커밋 메시지 수정
feat: snowflake 추가저장 후 종료하면 rebase가 완료됩니다.
4. 변경 사항 원격 반영 (Force Push)
git push --force-with-lease--force-with-lease: 원격 변경 사항이 있을 경우 push 차단- 단순
--force보다 안전
3. 결과 확인
3.1 커밋 히스토리 확인
git log --onelinefeat: 게시글 CRUD 기능 구현
chore: JPA 및 MySQL 의존성 추가
feat: snowflake 추가➡️ 잘못된 커밋 메시지가 정상적으로 수정됨
아래 내용을 그대로 이어 붙여서 쓸 수 있게, 기존 톤·형식 유지해서 정리해봤어요.
(블로그 글로 읽었을 때도 흐름이 자연스럽게 이어지도록 구성했습니다)
4. 공용 리포지토리였다면 어떻게 해야 했을까?
앞선 방법은 개인 리포지토리이기 때문에 문제없이 적용할 수 있었습니다.
하지만 **공용 리포지토리(팀 프로젝트)**에서 이미 push 된 커밋을 수정하는 경우에는
히스토리 변경이 팀원들에게 영향을 줄 수 있으므로 다른 접근이 필요합니다.
4.1 공용 리포지토리에서 Force Push가 위험한 이유
공용 브랜치(main, develop 등)에 대해 rebase + force push를 수행하면,
- 다른 팀원의 로컬 히스토리와 충돌 발생
- pull 시 rebase/merge 충돌 유발
- 최악의 경우 작업 내역 유실 가능
즉, 히스토리 재작성은 팀 전체에 영향을 주는 행위가 됩니다.
4.2 권장 방법 ①: 새로운 커밋으로 수정 (가장 안전)
이미 push 된 커밋 메시지가 잘못된 경우,
히스토리는 그대로 두고 새로운 커밋으로 보완하는 방식이 가장 안전합니다.
예시
기존 잘못된 커밋
featL snowflake 추가이를 바로 고치지 않고, 설명 보완 커밋 추가
git commit -m "chore: snowflake 기능 커밋 메시지 보완"장점
- 히스토리 변경 없음
- 팀원 영향 없음
- 리뷰·추적에 안전
단점
- 커밋 로그가 완벽하게 깔끔하지는 않음
4.3 권장 방법 ②: 관리자 합의 후 제한적 Rebase
정말로 커밋 히스토리 정합성이 중요한 경우
(예: 릴리즈 브랜치 정리, 오픈소스 메인 브랜치)
다음 조건을 모두 만족할 때만 rebase를 고려합니다.
사전 조건
- 해당 브랜치를 사용하는 인원이 극소수
- 모든 참여자에게 사전 공유 완료
- 작업 중인 사람이 없음을 확인
절차 개요
- 팀원에게 rebase 예정 공지
- Interactive Rebase로 커밋 수정
--force-with-lease로 push- 팀원들은 로컬 브랜치 reset 또는 rebase 수행
git fetch origin
git reset --hard origin/main4.4 상황별 정리
| 상황 | 권장 방식 |
|---|---|
| 개인 리포지토리 | Interactive Rebase + force-with-lease |
| 공용 리포지토리 (일반) | 새 커밋으로 보완 |
| 공용 리포지토리 (합의됨) | 제한적 rebase + 사전 공유 |