Git Fast-Forward vs Merge vs Rebase 완벽 정리

초기 상황 설정

# main 브랜치에서 시작
main: A ─ B ─ C
 
# feature 브랜치 생성
git checkout -b feature
feature: A ─ B ─ C ─ D ─ E
 
# hotfix 브랜치 생성 (main에서)
git checkout main
git checkout -b hotfix
hotfix: A ─ B ─ C ─ F ─ G

현재 상태:

main:    A ─ B ─ C
feature:         └─ D ─ E
hotfix:          └─ F ─ G

1. Fast-Forward Merge

조건

• 대상 브랜치에 새로운 커밋이 없을 때
• 현재 브랜치가 대상 브랜치의 직접적인 후손일 때

예시

# main으로 이동해서 feature를 merge
git checkout main
git merge feature

결과

main/feature: A ─ B ─ C ─ D ─ E
hotfix:               └─ F ─ G

특징

• ✅ 장점: 포인터만 앞으로 이동, 깔끔한 히스토리, merge 커밋 없음
• ❌ 단점: 브랜치 존재 흔적이 사라짐

2. 3-way Merge (Non-fast-forward)

조건

• 두 브랜치 모두 새로운 커밋이 있을 때
• 브랜치들이 diverged 상태일 때

예시

# main에 hotfix를 merge (main에는 이미 feature가 merge됨)
git checkout main
git merge hotfix

결과

main: A ─ B ─ C ─ D ─ E ─ M
               └─ F ─ G ─┘

특징

• ✅ 장점: 새로운 merge 커밋(M) 생성, 브랜치 히스토리 보존, 안전한 병합
• ❌ 단점: 복잡한 히스토리, merge 커밋 증가

3. Rebase

목적

• Linear한 히스토리를 만들고 싶을 때
• 커밋을 깔끔하게 정리하고 싶을 때

시나리오: auth 브랜치를 main 위에 재배치

# 초기 상태
main: A ─ B ─ C ─ H ─ I
auth:         └─ D ─ E ─ F
 
# auth 브랜치에서 rebase 실행
git checkout auth
git rebase main

결과

main: A ─ B ─ C ─ H ─ I
auth:                 └─ D' ─ E' ─ F'

특징

• ✅ 장점: 커밋들이 새로운 base 위에 재적용, 선형적이고 깔끔한 히스토리
• ❌ 단점: 커밋 해시 변경, 충돌 가능성, 공유된 브랜치에서는 위험

실제 프로젝트 예시

현재 브랜치 상황

main:        ... ─ M1 ─ M2
Feat/last-time:         └─ L1 ─ L2 ─ L3
Feat/auth:              └─ A1 ─ A2

1. Fast-forward (Feat/last-time → main)

git checkout main
git merge Feat/last-time  # Fast-forward 발생

결과: main: ... ─ M1 ─ M2 ─ L1 ─ L2 ─ L3

2. Fast-forward (main → Feat/auth)

git checkout Feat/auth
git merge main  # Fast-forward 발생

결과: Feat/auth: ... ─ M1 ─ M2 ─ L1 ─ L2 ─ L3 ─ A1 ─ A2

언제 어떤 방법을 사용할까?

Fast-Forward

# 개인 feature 브랜치, 선형 히스토리 원할 때
git merge feature-branch

사용 시기:

• 개인 작업 브랜치
• 빠른 hotfix
• 선형 히스토리를 유지하고 싶을 때

3-way Merge

# 브랜치 히스토리 보존하고 싶을 때
git merge --no-ff feature-branch

사용 시기:

• 팀 작업에서 브랜치 히스토리 보존
• Feature 완성 시점을 명확히 하고 싶을 때
• 롤백이 쉬워야 하는 경우

Rebase

# 깔끔한 히스토리, 커밋 정리하고 싶을 때
git rebase main
git rebase -i HEAD~3  # 대화형 rebase로 커밋 정리

사용 시기:

• 개인 브랜치 정리
• 커밋 메시지 수정
• 불필요한 커밋 제거
• PR 전 히스토리 정리

충돌 해결 차이

Merge 충돌

git merge feature
# 충돌 해결 후
git add .
git commit  # merge 커밋 생성

Rebase 충돌

git rebase main
# 충돌 해결 후
git add .
git rebase --continue  # 다음 커밋으로 계속
# 또는 중단: git rebase --abort

팀 작업 권장사항

1. Feature 브랜치 워크플로우

이유

Feature 브랜치 워크플로우 권장사항

워크플로우 단계

# 1. Feature 브랜치에서 작업
git checkout -b feature/new-function
 
# 2. 작업 완료 후 main 브랜치 최신화
git checkout main
git pull origin main
 
# 3. Feature 브랜치에 main 내용 rebase
git checkout feature/new-function
git rebase main
 
# 4. Main에 Fast-forward merge
git checkout main
git merge feature/new-function

왜 이 방식이 권장되는가?

1. 안전한 개발 환경

• 🛡️ main 브랜치 보호: 실험적 코드가 main에 영향 주지 않음
• 👥 병렬 작업: 여러 개발자가 동시에 다른 기능 개발 가능
• 🧪 실험 가능: 실패해도 main에 영향 없음

2. 최신 코드와의 호환성

• 📱 최신 반영: 다른 팀원의 변경사항 즉시 반영
• 🚫 충돌 최소화: 오래된 base에서 작업하지 않음
• 🔄 지속적 통합: 매번 최신 상태에서 개발

3. 깔끔한 히스토리

# ✅ 권장 방식: 선형 히스토리
main: A ─ B ─ C ─ D ─ E ─ F ─ G
              ↑feat1  ↑feat2
 
# ❌ 비권장: 복잡한 히스토리  
main: A ─ B ─ C ─ F ─ G ─ M1 ─ H ─ M2
           └─ D ─ E ─┘     └─ I ─┘

4. 안전한 충돌 해결

• ✅ 격리된 수정: feature 브랜치에서만 충돌 해결
• 🚫 main 보호: main 브랜치는 항상 안정적
• 💯 확신: merge 시점에 충돌 없음 보장

왜 충돌 해결이 안전한가?

충돌은 #3. rebase시에만 발생한다. 이를 모두 해결하고 난 뒤 main에 fast forward merge를 하면 충돌 가능성이 0%

git checkout feature/new-function
git rebase main  # ← 여기서 conflict 발생!
 
# 1. Conflict 파일 수정
# VS Code나 에디터에서 <<<< ==== >>>> 마커 해결
 
# 2. 수정된 파일 스테이징
git add .
 
# 3. Rebase 계속 진행
git rebase --continue
 
# 4. 추가 conflict가 있다면 1-3 반복

장점 요약

1. 개발 안전성: main 브랜치가 항상 안정적
2. 팀 협업: 병렬 개발과 코드 통합 용이
3. 히스토리 관리: 깔끔하고 추적 가능한 커밋 히스토리
4. 충돌 최소화: 체계적인 충돌 해결 과정

원본 링크

2. Release 브랜치

이유

Release 브랜치 전략

Release 브랜치 전략

권장 명령어

# Release 브랜치는 3-way merge로 히스토리 보존
git checkout main
git merge --no-ff release/v1.2.0

왜 3-way Merge를 사용하는가?

1. 릴리즈 히스토리 보존

# ✅ 3-way merge: 릴리즈 지점 명확
main: A ─ B ─ C ─ F ─ G ─ M
                └─ D ─ E ─┘
                  v1.2.0
 
# ❌ Fast-forward: 릴리즈 흔적 없음
main: A ─ B ─ C ─ D ─ E ─ F
                        ↑
                    v1.2.0?

2. 쉬운 롤백

• 🔄 빠른 복구: git reset --hard HEAD~1로 릴리즈 전 상태로 즉시 복구
• 📍 명확한 지점: 어디까지가 릴리즈인지 한눈에 파악
• 🛡️ 안전성: 문제 발생 시 신속한 대응 가능

3. 릴리즈 추적성

• 📅 시점 기록: 정확한 릴리즈 시간과 내용 추적
• 🏷️ 버전 연결: 태그와 merge commit의 명확한 연결
• 📝 변경 내역: 해당 릴리즈에 포함된 기능들 명확히 구분

Release 워크플로우

1. Release 브랜치 생성

git checkout -b release/v1.2.0 main

2. 릴리즈 준비 작업

# 버전 업데이트
echo "v1.2.0" > VERSION
git commit -m "Bump version to v1.2.0"
 
# 릴리즈 노트 작성
git commit -m "Update CHANGELOG for v1.2.0"

3. 테스트 및 버그 수정

# 릴리즈 관련 버그만 수정
git commit -m "Fix: Critical payment validation bug"

4. Main에 Merge

git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"

—no-ff 플래그의 중요성

Fast-forward의 문제점

• 릴리즈 작업이 일반 개발과 구분되지 않음
• 롤백 시 개별 커밋을 하나씩 되돌려야 함
• 릴리즈에 포함된 변경사항을 한눈에 파악하기 어려움

—no-ff의 장점

• 🎯 명확한 구분: 릴리즈 작업과 일반 개발 구분
• 📊 통계 가능: 릴리즈별 작업량 측정 용이
• 🔍 검토 용이: 릴리즈 범위를 한눈에 파악

Feature vs Release 비교

구분	Feature 브랜치	Release 브랜치
목적	새 기능 개발	릴리즈 준비
Merge 방식	Fast-forward	3-way merge (—no-ff)
히스토리	선형 유지	히스토리 보존
롤백	개별 커밋	전체 릴리즈 단위
추적성	기능별	버전별

장점 요약

1. 명확한 릴리즈 포인트: 언제 무엇이 릴리즈되었는지 명확
2. 쉬운 롤백: 문제 발생 시 빠른 복구 가능
3. 버전 관리: 체계적인 버전 히스토리 유지
4. 팀 커뮤니케이션: 릴리즈 범위와 내용을 쉽게 공유

원본 링크

3. Hotfix 브랜치

이유

Hotfix 브랜치 전략

Hotfix 브랜치 전략

권장 명령어

# Hotfix는 Fast-forward merge로 빠른 적용
git checkout main
git merge hotfix/critical-bug

왜 Fast-forward Merge를 사용하는가?

1. 신속한 배포

# ✅ Fast-forward: 즉시 적용
main: A ─ B ─ C ─ D ─ E ─ F
                        ↑
                   hotfix 즉시 적용
 
# ❌ 3-way merge: 불필요한 시간 소요
main: A ─ B ─ C ─ F ─ G ─ M
                └─ D ─ E ─┘
                  (시간 낭비)

2. 단순성 우선

• 🚨 긴급 상황: 복잡한 과정보다 빠른 해결이 우선
• 🎯 명확한 목적: 한 가지 문제만 해결 (보통 1-2개 커밋)
• ⚡ 즉시 반영: merge commit 생성 시간도 절약

3. 실수 방지

• 🚫 복잡성 제거: 긴급 상황에서 단순한 과정으로 실수 최소화
• 🔧 집중: 문제 해결에만 집중, 히스토리 관리는 나중에
• ✅ 확실성: 빠르고 확실한 적용

Hotfix 워크플로우

1. 긴급 상황 발생

🚨 ALERT: Critical production bug detected!

2. Hotfix 브랜치 생성

git checkout main  # 현재 프로덕션 버전
git checkout -b hotfix/payment-crash

3. 빠른 수정

git commit -m "Fix: Null pointer exception in payment validation"

4. 즉시 배포

git checkout main
git merge hotfix/payment-crash  # Fast-forward
git tag v1.2.1  # 간단한 태그 (배포 트리거)
git push origin main v1.2.1

5. 다른 브랜치에도 반영

# 개발 브랜치에도 적용 (중복 버그 방지)
git checkout develop
git merge hotfix/payment-crash

시간 비교 예시

Fast-forward 방식 (권장)

13:00 - 버그 발견
13:05 - hotfix 브랜치 생성  
13:15 - 수정 완료
13:16 - merge, 태그, 푸시
13:20 - 서비스 정상화

3-way merge 방식 (비권장)

13:00 - 버그 발견
13:05 - hotfix 브랜치 생성
13:15 - 수정 완료  
13:18 - merge commit 작성
13:22 - merge 완료 및 배포
13:27 - 서비스 정상화

결과: 7분의 다운타임 단축!

브랜치별 전략 비교

구분	Feature	Release	Hotfix
긴급도	낮음	중간	🚨 높음
Merge 방식	Fast-forward	3-way merge	Fast-forward
이유	깔끔한 히스토리	히스토리 보존	빠른 배포
우선순위	품질	계획성	속도

언제 Hotfix를 사용하는가?

✅ Hotfix 사용 상황

• 🚨 프로덕션 장애: 서비스 중단 상황
• 🔒 보안 취약점: 즉시 패치 필요
• 💰 비즈니스 크리티컬: 매출에 직접 영향
• 📊 데이터 무결성: 데이터 손실 위험

❌ Hotfix 남용 주의

• 🐛 일반적인 버그 → 다음 릴리즈 포함
• 🎨 UI 개선 → 계획된 개발 진행
• ⚡ 성능 최적화 → Feature 브랜치 사용
• 📱 새로운 기능 → Feature 브랜치 사용

주의사항

필수 체크리스트

• ✅ 테스트: 빠르더라도 핵심 테스트는 필수
• ✅ 문서화: 긴급 수정 내용 기록
• ✅ 전파: 모든 관련 브랜치에 반영
• ✅ 모니터링: 배포 후 즉시 확인

장점 요약

1. 최대 속도: 긴급 상황에서 가장 빠른 대응
2. 단순성: 복잡한 과정 없이 즉시 적용
3. 실수 방지: 간단한 워크플로우로 실수 최소화
4. 집중: 문제 해결에만 집중 가능

원본 링크

주의사항

⚠️ Rebase 사용 시 주의점

• 절대로 공유된 브랜치를 rebase하지 마세요
• 이미 push된 커밋을 rebase하면 다른 팀원에게 문제 발생
• git push --force는 매우 위험함

🔍 히스토리 확인 명령어

# 그래프로 히스토리 보기
git log --oneline --graph --all
 
# 특정 브랜치 간 차이 보기
git log main..feature
 
# 머지 커밋만 보기
git log --merges

정리

방법	사용 시기	장점	단점
Fast-forward	개인 작업, 간단한 변경	깔끔한 히스토리	브랜치 흔적 없음
3-way Merge	팀 작업, 중요한 기능	히스토리 보존, 안전	복잡한 그래프
Rebase	커밋 정리, 선형 히스토리	깔끔한 라인	위험성, 충돌 가능

상황에 맞게 선택하여 깔끔하고 추적 가능한 Git 히스토리를 유지하세요!