Git Rebase와 Merge: 언제 무엇을 사용할지
Git에서 가장 많이 논의되는 결정 중 하나는 다음과 같습니다. 리베이스 또는 병합 사용? 둘 다 그들은 한 지점에서 다른 지점으로 변경 사항을 통합하지만 근본적으로 다른 방식으로 통합합니다. 이해하기 각각의 차이점, 장점, 단점은 스토리를 유지하는 데 필수적입니다. Git을 정리하고 팀으로서 효과적으로 협업하세요.
🎯 무엇을 배울 것인가
- 리베이스와 병합의 근본적인 차이점
- 리베이스를 사용하는 시기와 병합하는 시기
- 빨리 감기 병합과 병합 커밋
- 리베이스의 황금률
병합 작동 방식
힘내 병합 새로운 것을 만들어라 병합 커밋 이야기를 하나로 묶는 것 두 가지 중. 수술이에요 비파괴적인: 원래 가지가 안 나오네요 수정되었습니다.
# Situazione iniziale
main: A---B---C
\
feature: D---E
# Merge di feature in main
git checkout main
git merge feature
# Risultato
main: A---B---C-------M
\ /
feature: D---E---
# M è il merge commit che ha due genitori: C ed E# Passa al branch di destinazione
git checkout main
# Mergia il feature branch
git merge feature
# Git crea automaticamente un merge commit
# Messaggio default: "Merge branch 'feature' into main"리베이스 작동 방식
Git 리베이스 다시 작성 지점의 커밋을 이동하여 기록 새로운 기준으로. 병합 커밋을 생성하는 대신 커밋이 다시 적용 대상 지점의 끝에서 하나씩.
# Situazione iniziale
main: A---B---C
\
feature: D---E
# Rebase di feature su main
git checkout feature
git rebase main
# Risultato
main: A---B---C
\
feature: D'---E'
# D' ed E' sono NUOVI commit con contenuto uguale a D ed E
# ma hash diversi (perché il parent è cambiato)# Passa al feature branch
git checkout feature
# Rebase su main
git rebase main
# I commit di feature vengono riapplicati su main
# Se ci sono conflitti, risolvili e:
git add .
git rebase --continue
# Ora puoi fare fast-forward merge su main
git checkout main
git merge feature # Fast-forward (nessun merge commit)빨리 감기 병합
Un 빨리 감기 병합 대상 브랜치에 커밋이 없을 때 발생 new는 병합할 브랜치와 비교됩니다. Git은 포인터 없이 포인터를 "앞으로 이동"합니다. 병합 커밋을 만듭니다.
# Situazione dopo rebase
main: A---B---C
\
feature: D'---E'
# Fast-forward merge
git checkout main
git merge feature
# Risultato (nessun merge commit)
main: A---B---C---D'---E'
|
feature: 빨리 감기를 방지하고 병합 커밋을 강제하려면 다음을 수행하세요.
git merge --no-ff feature주요 차이점
병합:
- 분기 내역: 가지가 갈라졌을 때 표시
- 비파괴: 원작 스토리 보존
- 추적 가능: 병합이 발생한 정확한 시간 확인
- 안전한: 역사를 다시 쓰지 않음
- 추가 병합 커밋 만들기
리베이스:
- 선형 이야기: 마치 순차적으로 작업한 것처럼
- 파괴적: 커밋 재작성(새 해시)
- 깨끗한: 시끄러운 병합 커밋 없음
- 위험한: 절대 공개 지점을 리베이스하지 마세요!
- 더 읽기 쉬운 이야기
병합을 사용하는 경우
✅ 다음과 같은 경우에 병합을 사용하세요:
- 손대지 않은 공공 지점 (메인, 개발)
- 당신이 원하는 역사를 보존하다 정확히 가지가 갈라졌을 때
- 당신은 다음에서 일합니다 team 다른 사람들은 이미 지점을 뽑았습니다
- 추적하고 싶으신가요? 이정표 (완성된 기능, 릴리스)
- 따르다 힘내 흐름 (미국
--no-ff구조를 보존하기 위해)
# Feature branch completato
git checkout main
git merge --no-ff feature/user-auth
# Merge commit preserva la storia della feature
# Chiaro quando la feature è stata integrata
# Altri sviluppatori vedono la struttura completa리베이스를 사용해야 하는 경우
✅ 다음과 같은 경우에 리베이스를 사용하세요:
- 당신은 노력하고 있습니다 개인 지역 지점
- 당신이 원하는 선형적인 이야기 깨끗한
- 메인의 최신 변경 사항으로 기능 브랜치를 업데이트하고 있습니다.
- "시끄러운" 병합 커밋을 피하고 싶습니다.
- Pull Request를 작성하기 전 (클린 스토리를 위해)
# Il tuo feature branch è indietro rispetto a main
git checkout feature/payment
git rebase main
# Ora il tuo branch ha gli ultimi cambiamenti da main
# Storia lineare, facile da revieware nella PR
# Risolvi conflitti se necessario
# git add .
# git rebase --continue리베이스의 황금률
⚠️ 황금률
공유 공개 브랜치로 푸시된 커밋을 리베이스하지 마세요!
리베이스는 커밋 해시를 변경하여 기록을 다시 작성합니다. 다른 개발자가 있다면 이미 해당 커밋을 기반으로 작업을 수행하면 저장소가 일관성이 없게 되고 다음 풀에서는 충돌과 중복이 발생합니다.
# MALE! Altri hanno già pullato main
git checkout main
git rebase feature
# Questo riscrive main, causando problemi per tutti# BENE! feature è solo tuo, nessuno l'ha pullato
git checkout feature
git rebase main
# Aggiorna il tuo branch privato con gli ultimi cambiamenti권장되는 작업 흐름
다음은 두 가지의 장점을 결합한 워크플로입니다.
# 1. Crea feature branch da main
git checkout -b feature/new-feature main
# 2. Lavora sulla feature
git commit -m "feat: add component"
git commit -m "feat: add tests"
# 3. Nel frattempo, main è andato avanti
# Aggiorna il tuo branch con rebase (branch privato, OK!)
git fetch origin
git rebase origin/main
# 4. Pulizia della storia con interactive rebase (opzionale)
git rebase -i origin/main
# Squash commit WIP, fixup typos, ecc.
# 5. Push del feature branch
git push origin feature/new-feature
# 6. Crea Pull Request su GitHub/GitLab
# 7. Dopo code review, mergia in main CON merge commit
git checkout main
git merge --no-ff feature/new-feature
# Risultato: storia main pulita con milestone chiare선형 및 분기 기록
병합 기록:
* Merge feature B
|\
| * Feature B commit 2
| * Feature B commit 1
* | Main commit 3
* | Main commit 2
|/
* Main commit 1장점: 기능이 언제 통합되었는지 정확히 확인하세요.
와 함께: 병합이 많으면 지저분해질 수 있습니다.
리베이스를 사용한 기록:
* Feature B commit 2
* Feature B commit 1
* Main commit 3
* Main commit 2
* Main commit 1장점: 선형적이고 따라하기 쉽습니다.
와 함께: 분기가 언제 갈라졌는지에 대한 정보를 잃습니다.
충돌: 병합과 리베이스
둘 다 충돌이 있을 수 있지만 다르게 처리됩니다.
# Conflitti durante MERGE
git merge feature
# Risolvi conflitti
git add .
git commit # Completa il merge
# Conflitti durante REBASE
git rebase main
# Risolvi conflitti per ogni commit in conflitto
git add .
git rebase --continue # Vai al prossimo commit
# Ripeti fino alla fine
# Abortire rebase se necessario
git rebase --abort팀 선호도
팀마다 선호도가 다릅니다. 몇 가지 예:
- 리눅스 커널: 병합만(전체 기록 보존)
- 울타리: 기능 분기를 위한 리베이스, 중요한 통합을 위한 병합
- Google: 리베이스를 사용한 선형 기록(트렁크 기반 개발)
결론
병합과 리베이스 사이에 보편적인 "최상의" 선택은 없습니다. 병합 보존하다
역사이며 공공 지점에서는 안전합니다. 리베이스 깔끔한 선형 스토리를 만듭니다.
그러나 커밋을 다시 작성합니다. 가장 좋은 전략은 하이브리드인 경우가 많습니다. 리베이스를 사용하여 깨끗하게 유지하세요.
로컬 기능 분기를 사용하고 다음과 병합합니다. --no-ff 공공 지점에 통합합니다.
🎯 핵심 포인트
- 병합 = 비파괴적, 병합 커밋 생성, 분기된 기록
- 리베이스 = 기록 재작성, 병합 커밋 없음, 선형 기록
- 절대 공유 공용 브랜치를 리베이스하세요.
- 비공개 기능 브랜치에는 리베이스를 사용하고 공개 통합에는 병합을 사용하세요.
- 빨리 감기 병합 = 가능한 경우 병합 커밋 없음