Git에서 브랜치를 병합할 때 merge나 pull 명령어와 함께 자주 등장하는 옵션이 있다.
--ff, --no-ff, --squash이다.
모두 병합의 히스토리 관리 방식과 관련이 있으며, 어떤 옵션을 쓰느냐에 따라 프로젝트 히스토리가 크게 달라진다.
1. --ff (fast-forward merge)
fast-forward merge는 Git의 기본 동작
대상 브랜치가 단순히 뒤쪽에만 커밋이 이어져 있는 경우,
새로운 병합 커밋을 만들지 않고 브랜치 포인터만 앞으로 이동시킨다.
장점
- 히스토리가 직선으로 이어져 깔끔하다
- 불필요한 merge commit이 생기지 않는다
단점
- 브랜치가 존재했다는 흔적이 남지 않는다
- 협업 시 어떤 기능이 어느 브랜치에서 개발되었는지 추적하기 어렵다
사용 시점
- 기능 브랜치를 짧게 만들어 금방 병합할 때
- 작은 수정이나 개인 작업 등에서 히스토리를 단순하게 유지하는 것이 목표일 때
2. --no-ff (no fast-forward merge)
fast-forward가 가능하더라도 강제로 병합 커밋을 생성하는 방식
결과적으로 브랜치가 갈라졌다는 기록이 남는다.
장점
- 브랜치 단위의 개발 기록을 보존할 수 있다
- 어떤 기능이 어떤 브랜치에서 개발되었는지 명확히 남는다
- 이후 특정 기능 브랜치를 되돌리거나 추적할 때 유리하다
단점
- merge commit이 쌓이면서 히스토리가 다소 복잡해진다
사용 시점
- 팀 프로젝트에서 기능 단위 기록을 보존해야 할 때
- Git Flow 같은 브랜치 전략을 따를 때
- 특정 기능 단위로 revert 작업이 발생할 수 있을 때
3. --squash (squash merge)
여러 개의 커밋을 하나의 커밋으로 합쳐서 대상 브랜치에 병합하는 방식
병합 커밋은 따로 생성하지 않고 단일 커밋으로만 반영된다.
main에는 브랜치 히스토리가 남지 않는다
브랜치를 삭제하지 않는다면, 작업했던 세부 커밋 기록은 원래 브랜치 안에만 남아있다
장점
- “기능 단위 = 하나의 커밋”으로 정리되어 히스토리가 매우 깔끔하다
- 중간에 발생한 실수 commit, 자잘한 commit 기록이 본선(main)에 남지 않는다
단점
- 브랜치에서 작업한 세부 히스토리가 main에는 남지 않는다 (작업 브랜치에만 존재)
사용 시점
- 실험적인 기능을 테스트하다가 최종 결과만 반영하고 싶을 때
- 코드 리뷰 후 main에는 최종 결과만 반영하고 싶을 때
- 개인 사이드 프로젝트처럼 히스토리를 미니멀하게 관리하고 싶을 때
- --ff: 브랜치 흔적 없이 단순한 히스토리 → 작은 작업, 개인 작업
- --no-ff: 브랜치 단위 기록 유지 → 협업, 팀 프로젝트
- --squash: 여러 커밋을 하나로 정리 → 실험 브랜치, 깔끔한 main 유지
- 기능별 브랜치 추적이 필요하다면 → --no-ff
- 테스트/실험 후 결과만 반영하고 싶다면 → --squash
- 작은 단일 수정이라면 → --ff
반응형
'IT > Git & GitHub' 카테고리의 다른 글
Git 핵심 개념 (0) | 2025.10.12 |
---|---|
Git과 Github - 개발자가 알아야 할 버전 관리의 시작점 (0) | 2025.10.12 |
Git 커밋 메시지 규칙 (0) | 2024.10.26 |
GitHub (0) | 2024.08.03 |