Merge

출처 : https://meetup.toast.com/posts/122

• a, b, c 를 참조 하는 m 커밋 노드 생성, m은 parent로 Init, c 를 가짐

Squash & Merge

출처 : https://meetup.toast.com/posts/122

• a, b, c 를 합쳐서 새로운 커밋으로 생성 후, 머지 대상 브랜치에 추가
• 'a,b,c' 커밋은 parent를 Init 하나만 가짐.

Rebase & Merge

출처 : https://meetup.toast.com/posts/122

• a, b, c 를 머지 대상 브랜치에 일직선으로 추가, 각 커밋들은 모두 parent를 하나씩만 가짐.

실습

시나리오

1. main 브랜치에 first, second 커밋이 존재한 상태
2. 새로운 이슈를 처리하기 위해 feature 브랜치 생성 후 commit (feature_1, feature2)을 기록
3. 갑자기 중요한 수정사항이 들어옴. hotfix 브랜치를 생성 후 commit (hotfix) 을 기록
4. main 브랜치로 이동하여 hotfix → feature 브랜치 순으로 merge 작업

Merge

$ git merge hotfix
$ git merge feature

• second(공통 조상), feature_2, hotfix 3개 커밋의 3-way Merge 결과를 별도의 커밋(m)으로 만든다.

Squash & Merge

#1

$ git merge --squash hotfix
$ git merge --squash feature
$ git commit -m "hotfix & feature"

• hotfix 브랜치의 커밋과 feature 브랜치의 커밋을 합쳐 새로운 "hotfix & feature" 커밋 생성
• 작업했던 브랜치의 각각의 커밋들과는 별개로 새로운 하나의 커밋이 생성된 것. (연관없음)

#2

$ git merge hotfix
$ git merge --squash feature
$ git commit -m "feature"

• hotfix는 일반적인 merge
• feature 브랜치의 커밋(feature_1, feature_2)만 하나의 새로운 커밋으로 생성

Rebase

$ git rebase hotfix
$ git rebase feature

• 모든 커밋들을 일직선으로 기록
• 원래 존재하는 브랜치의 각 커밋에 대해 새로운 커밋을 생성하여 프로젝트 기록을 다시 작성(주의)

사용예시

Git Flow 를 따른다고 했을 때, 아래와 같이 정리

• develop - feature 브랜치간 머지

  • Squash and Merge가 유용
  • feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브랜치에 추가하여, develop 브랜치에서 독자적으로 관리

• master - develop 브랜치간 머지

  • Rebase and Merge가 유용
  • develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문이다.

• hotfix - develop, hotfix - master 브랜치간 머지

  • Merge 또는 Squash and Merge모두 유용. 때에 따라 골라 사용.
  • hotfix 브랜치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용

References

• https://meetup.toast.com/posts/122
• https://medium.com/@shubhpaliwal98/when-to-use-squash-merge-and-rebase-43da3571dcbe
• 출처가 없는 사진은 직접 캡쳐