GIT 파헤쳐보기: git 기초(3) - 3-way merge

 🔗 3-way merge

0️⃣  비교: fast-forward merge

fast-forward merge는 merge의 가장 기본이 되는 개념으로, 각 master branch를 가리키고 있는 pointer가 가장 최신의 커밋으로 이동한다.

 

단, master branch로 checkout할 때, issue 53 branch가 깨끗해야 한다. (아닐 경우, git stash 이용해서 tree를 clean하게 만들어 주고 checkout을 해야 함)

 

 

1️⃣ 기본개념: Three Way Merge

 

1. 3-way merge가 일어나는 상황

1. A라는 작업자가, issue53이라는 기능을 완성하기 위해서 C5브랜치에서 작업을 하던 도중,
2. B라는 작업자가 master branch에서 갑작스럽게 일어난 오류 등을 고치기 위해서 수정을 가했을 때
3. 해당 작업들을 merge하는 것이 필요한데, 이러한 경우에는 상기 fast-forward merge가 작동하지 않는다: 이때 3-way merge 방법을 사용할 수 있다
   • C4가 되돌아가지(backtrack) 않고는 가장 최근 커밋인 C5에 도달할 수 없으므로 fast-forward가 동작하지 않는 것!

 

2. 어떻게 merge 하나요?

1) 개요

3-way merge

1. C4와 C5의 ✨공통 조상(Common Ancestor: C2)✨을 찾는다 -- 이게 3-way merge의 포인트!
2. C2, C4, C5 파일 상태를 각각 확인한 후 merge commit을 할 수 있음( 너무 당연해보이지만 정말 이게 끝 )
   1. C4, C5을 merge해 준다 ( master로 넘어가서 iss53을 merge 해줌)

C4와 C5가 merge 된 상태의 커밋은 C6으로 찍힘

 

2) 실습

위에서 설명한 것들을 git bash에서 직접 해본다면 아래와 같다!

• 일단 iss53 branch에서 변경사항들을 commit해준다

$ git add .
$ git commit -m "test"

• master branch로 넘어가서 해당 상황을 commit 해준다

$ git checkout master
$ git add .
$ git commit -m "test on master"

• 이 둘을 fast-forward merge할 수 없음 ( 일단 메세지부터 fast-forward아니라 recursive merge라고 나옴 )

$ git merge iss53

Merge made by the 'recursive' strategy

•  

 

2️⃣ 논란: 2-way merge vs 3-way merge

1. 결론: 3-way merge가 더 효과적이다

• '기준'이 되는 원본 코드가 없다면, 최신 커밋끼리 비교하는 2-way merge를 해도 어떤 커밋이 더 '바람직한' 커밋인지 판단하기가 어렵다.
• 결론적으로, 3-way merge가 2-way merge보다 훨씬 안전하고 오류(!=conflict)가 덜 나는 방법이다

 

2. 예제 1

1. 원래 ABC였던 코드를, 작업자 A가 iss53 브랜치에서 BC로 수정을 하고
2. 작업자 B가 master branch에서 ABCD라고 수정을 함
3. 공통조상은 ABC인 상황

• 2-way merge의 경우
  • ABCD와 BC를 비교
  • 어느 커밋이 올바른지 알 수 없음
• 3-way merge의 경우
  • ABC, ABCD, BC를 비교
  • 따라서 ABC를 보고 master에서 어떤 부분이 추가되었고(+D), iss53에서 어떤 부분이 삭제되었는지(-A) 보다 명확히 알 수 있게 됨
  • conflict를 해결하고 add, commit!

 

3. 예제 2

• 2-way merge의 경우
  • C4(Apple, Berry Citron) vs C5(Apricot, Banana, Coconut)
  • 두 코드가 전부 다르므로, 세 군데에서 모두 conflict이 일어난다
• 3-way merge의 경우
  • 위와 같은 상황에서는, 3-way merge가 자동적으로 되는 경우가 있다
    • 한 쪽이 변경사항이 없고, 다른 한 쪽이 변경사항이 있는 경우, 변경사항이 있는 쪽으로 적용된다
    • 따라서, Cherry - Citron - Coconut 부분에서만 conflict이 일어나고 나머지는 자동으로 merge된다
  • 위의 상황에서 merge된 이후의 코드는 아래와 같다

  Apricot # Apple에서 변경 일어난 iss53 따라감
  Berry	# Banana에서 변경 일어난 master 따라감
  Cherry # Cherry vs Citron vs Coconut # CONFLICT!

  • 만약 Cherry의 경우처럼 두 개의 commit 모두에서 수정이 일어났을 경우, conflict이 발생하면 manually resolve 해주어야 한다

 

•  

---

📌 참고문서/블로그

• git scm official documentation https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
• stackoverflow | Why is a 3-way merge advantageous over a 2-way merge? https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge
• Conquering Git: Advanced Training Guide: Fast-Forward or 3-Way Merge https://www.youtube.com/watch?v=NDGjZwQrGF0&ab_channel=PacktVideo
• SW Developer https://wonyong-jang.github.io/git/2021/02/05/Github-Merge.html
• Plus Ultra https://overcome-the-limits.tistory.com/entry/git-git-3-way-merge%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90
• 24. How to perform a merge operation | 3 Way Merge | Git Merge | Git tutorial for beginner https://www.youtube.com/watch?v=0yZ0hV_BBuk

---

 

블로그 내용에 문제가 있다면 댓글 혹은 아래로 연락주세요!

~대가리 꽃밭인 디지털 노마드가 꿈이예요~

🧚‍♀️ Gyumin Lee

📧 gyumin.q.lee@gmail.com

qminlee723 - Overview