Git branch merge 종류와 특징

1. Git merge?

merge = 병합하다

git branch를 다른 branch와 병합하는 과정을 merge라고 한다.

2. Git merge의 종류

Fast-Forward Merge

• 브랜치가 분기되지 않은 상태에서 진행한다.
• 새로운 변경 사항이 없는 main 에서 새로운 변경 사항이 있는 stage 를 merge 할 때 사용
• 혼자 작업하거나, 단순한 작업을 추가하는 경우 사용한다.

git branch stage # 작업을 위한 브랜치 생성
git checkout stage # 브랜치 이동

# 작업 후
git add .
git commit -m "작업 브랜치에서의 변경 상태를 commit 해야 다른 브랜치로 이동 가능"
//원격에 push가 필요할 경우 push하고 이동

git checkout main # merge 할 브랜치로 이동. main에는 변화가 없음. stage의 변경 사항만 
									# 받아옴
git merge stage

# 결과 히스토리
A -- B -- C (main)
           \
            D -- E (stage)
            
Fast-Forward 후:
A -- B -- C -- D -- E (main, stage)

3-way Merge(Recursive Merge)

• 브랜치가 분기된 상태에서 이루어진다.
• main 브랜치와 stage 브랜치 모두에서 변경 사항이 존재하는 경우 사용된다.
• 두 변경 사항을 통합하고 병합 커밋을 작성하는데, 이 과정에서 충돌이 발생할 수 있다.
  • IDE 기능으로 충돌 수정
  • Pull Request web edit을 통해 수정
• 팀 프로젝트에서 여러 개발자가 동시에 다른 브랜치에서 작업한 경우에 사용한다.

git branch stage # 작업을 위한 브랜치 생성
git checkout stage # 브랜치 이동

# 작업 후
git add .
git commit -m "작업 내용 commit"
//원격에 push가 필요할 경우 push하고 이동

git checkout main
# 작업 후
git add .
git commit -m "작업 내용 commit"
git merge stage # 병합 커밋 생성, 충돌이 발생할 수 있음

# 결과 히스토리
A -- B -- C -- F -- G (main)
           \
            D -- E (stage)
            
Recursive Merge 후:
A -- B -- C -- F -- G -- H (main)
           \         /
            D ------ E
# H가 병합 커밋

Rebase & Merge

• 브랜치가 뻗어나온 기준점을 변경하는 것(재배치)
  • 브랜치의 기준점을 최근 커밋으로 옮긴 후 Fast-Forward Merge를 진행한다.
• 하나의 브랜치에서 작업한 것과 같은 효과를 낼 수 있기 때문에 히스토리가 깔끔해진다.
  • 하지만 재배치를 하면 기존 커밋이 각각 재작성되면서 새로운 커밋이 생성된다.
• 이미 다른 개발자가 공유한 브랜치를 rebase하면, 히스토리 변경으로 인해 충돌과 혼란이 발생할 수 있기에 협업 중인 브랜치에 사용하지 않는 것이 좋다.

git checkout stage
 
# stage 브랜치를 main 브랜치로 재배치
git rebase main
 
# main 브랜치로 이동
git checkout main
git merge stage

# 결과 히스토리
A -- B -- C (main)
       \
        D -- E (stage)
        
# D, E가 가진 커밋이 각각 재작성 되어 merge
# 이 과정에서 충돌이 일어날 수 있음
A -- B -- C -- D! -- E! (stage)

Squash & Merge

• 작업 브랜치의 여러 개의 커밋을 하나의 커밋으로 압축하여 병합하는 방법
• 불필요한 히스토리를 숨길 수 있다.
  • 이 과정에서 세부 커밋 히스토리가 사라지므로 과거 변경 사항을 추적 하기가 어렵다.
  • 따라서 작업 브랜치의 내용이 필요하면, feature 브랜치를 따로 유지하여 기록을 보존하는 것이 좋다.

# 결과 히스토리
main:
A -- B -- C

feature (stage 브랜치):
A -- B -- C
          \
           D -- E -- F
           
# squash merge 
main:
A -- B -- C -- G

3. Git log

git log 명령어를 통해 히스토리와 체크섬을 확인할 수 있는데, 체크섬 앞자리 일부를 입력하여 버전을 바꿀 수 있다. 커밋 메세지를 잘 적어야 버전 관리에 용이하다.

git checkout <커밋 해시>

# 예시. codeit sprint css 실습 과제 - 항공편 티켓 예매 페이지 버전으로 이동
git checkout ebe3

체크섬(checksum): 송신된 자료의 무결성을 보호하기 위해 해싱된 데이터

ref: https://hudi.blog/git-merge-squash-rebase/