[Git] master 관리자가 MR 요청한 브랜치의 conflict 해결하기

<분류>
A. 수단
- OS/Platform/Tool : Linux, Kubernetes(k8s), Docker, AWS
- Package Manager : node.js, yarn, brew, 
- Compiler/Transpillar : React, Nvcc, gcc/g++, Babel, Flutter
- Module Bundler  : React, Webpack, Parcel

B. 언어
- C/C++, python, Javacsript, Typescript, Go-Lang, CUDA, Dart, HTML/CSS

C. 라이브러리 및 프레임워크 및 SDK
- OpenCV, OpenCL, FastAPI, PyTorch, Tensorflow, Nsight

 

---

1. What? (현상)

먼저, 다른 글에서 보였듯이 git branch를 merge하는데는 아래와 같은 두가지 관계가 존재합니다.

** https://tkayyoo.tistory.com/86

• fast-forward(ff) 관계 : History가 포함관계 일 때
  
  • Branch1의 Commit history : A > B > C > D
  • Branch2의 Commit history : A > B 
• non-ff 관계 : History가 포함관계가 아닐 때
  
  • Branch3의 Commit history : A > B > C
  • Branch4의 Commit history : A > B > D

ff인 경우 문제가 없겠지만, non-ff인 경우 Three-way Merge, Rebase merge, Cherry Picking Merge등의 방법을 활용해서 merge를 하곤 합니다.

 

이건 일반적인 이야기니, 조금 더 자세한 상황을 살펴보겠습니다. 아래와 같이 메인 개발자인 A작업자와, 서브 개발자인 B 작업자가 있을 때, 두가지 상황을 나누어 살펴보겠습니다

• A개발자 : Master를 관리합니다.
• B개발자 : Branch4라는 브랜치를 만들어 master에 MR를 할 예정입니다.
  ** GitLab MR(Merge Request) == Github PR(Pull Request)

---

 

상황1. 두 개발자 모두 작업을 진행했는데, A개발자가 이미 master를 변경해버렸습니다. 

• Master
  • Local Commit history : A > B > C
  • Remote Commit history : A > B > C
• Branch4
  • Local Commit history : A > B > D
  • Remote Commit history : A > B

 

이런 경우 사실 B개발자가 git pull을 한 뒤에 Branch4에 git push하고 MR을 날리면 됩니다. 

• Branch4
  • Local Commit history : A > B > D > D+C
  • Remote Commit history : A > B > D+C ~ MR!

이 때 git pull을 하는 시점에서 문제가 발생할텐데, git pull 은 git fetch + git merge이므로 이전 글에서 소개했던 것과 비슷하게 아래와 같은 코드로도 해결이 가능합니다.

** https://tkayyoo.tistory.com/44

git stash
git pull origin master
git stash pop

 

단, conflict marker가 생길 것이기 때문에 파일마다 이들을 해결해 줍니다.

 

또한, 위 방법은 non-ff 상황에서 git pull에 포함된 git merge를 활용해 단순히 three-way merge를 한 것인데, git rebase를 활용해서 하면 history가 조금더 깔끔해지기도 합니다.

** https://orangebrother.dev/blog/dont-ever-use-git-pull

 

---

상황2. 두 개발자 모두 작업을 진행했는데, B개발자가 이미 master에 merge를 원하는 MR을 날려버렸습니다.

• Master
  • Local Commit history : A > B > C
  • Remote Commit history : A > B 
• Branch4
  • Local Commit history : A > B > D
  • Remote Commit history : A > B > D ~ MR!

이런 경우 사실 pull을 진행한 후에 다시 MR을 날리도록 요청하는 것이 일반적이나, master가 직접 merge하려면 어떻게 하면 좋을까요?

---

2. Why? (원인)

• X

---

3. How? (해결책)

 

방법은 총 2가지가 있습니다.

 

1. Git의 Resolve conflicts를 활용하기

 

Git에서 제공하는 충돌을 해결하는 방법이 있기 때문에 A개발자는 그냥 Master에 push 해버리고, Interactive Mode 및 Edit inline 두가지 모드를 활용해 충돌을 해결할 수 있습니다.

• Master
  • Local Commit history : A > B > C 
  • Remote Commit history : A > B > C > C+D

 

아래는 다른 사이트에서 제공해준 Interactive Mode인데, 왼쪽 오른쪽 중 선택해 "Use this"를 통해 선택후에 새로 커밋을 만들어 해결해줍니다.

[https://thsd-stjd.tistory.com/138]

 

2. Local에서 해결하는 방법

 

MR을 local에서 merge해 버리고, 새로 remote에 push해버리는 방법입니다. 

• Master
  • Local Commit history : A > B > C > C+D
  • Remote Commit history : A > B > C+D

 

먼저 remote의 정보를 가져와야 하므로 아래 명령어를 실행해준 후에

git fetch --all

 

개발자A가 나의 브랜치인지를 재확인 한 후에

git checkout master

 

해당 브랜치를 merge해줍니다.

git merge Branch4

 

역시나 아래와 같은 conflict marker가 생길 것이기 때문에 파일마다 이들을 해결해 줍니다.

<<<<<<< HEAD
    my local commit
=======
    pulled commit
>>>>>>> 8dcbf52aea6c16

---

https://thsd-stjd.tistory.com/138