Merge - fast forward / 3 Way merging 전략

< merge >

로컬에서 작업하면서 Branch 를 생성해서 작업했다면,

각 branch 별로 기능들 나눠져 있는걸 잘 정리정돈 해서, 하나로 만들어서 Push 해야 한다.

 

이 정리정돈 해주는 놈이 바로 merge 기능.

명령어는 매우 간단하다.

 

git merge 브랜치이름

 

보통 로컬도 master 브랜치를 메인으로 쓰기때문에,

master 브랜치에다가 나머지 자잘구리한 기능들을 합체 시키는 것이다.

( master 브랜치로 switch 해서 이동한 후에, 자잘구리들을 merge 해준다. )

 

근데, 이 자잘구리 Branch 가 하나 일때는 별 문제가 없는데, 2개 이상이 되면, 조금 복잡해진다.

 

*1. 자잘구리 Branch 1개 => "fast-forward merging 전략" (기본 전략) *

 

master 브랜치에서 잘 커밋을 해오고 있다.
commit 1
commit 2
commit 3
...
commit 99 < HEAD , master >

 

그러다가 독립적으로 만들어야 할 기능이 생겼다.
master 에 commit 해놓은게 부숴질까 걱정이다.
새로운 branch 방을 파서 거기서 작업해야겠다.

 

git branch Login
git switch Login

 

Newcommit 1
Newcommit 2
Newcommit 3 < HEAD, Login > ( HEAD 는 commit 에서 Newcommit3 으로 옮겨졌다. / master 는 여전히 commit99 )

 

끝났다.
merge하자

 

git switch master
git merge Login

 

잘됬다. 이제 쓸모없어진 브랜치 삭제하자

 

git branch -d Login ( 머지 잘 됬는 지 꼭 확인하고 )

 

// 끝

하나일 땐 참 쉽다.

 

 

*2. 자잘구리 Branch 2개 이상 => "3 Way merging 전략" (실제로 많이 쓰임) *

근데 위의 경우에서 추가한 Branch가 Login 하나가 아니라 하나 더 있었다고 해보자

 

master
Login
Logout

 

master 에서 Login 브랜치를 fastforward 전략으로 머징하고 ( Login 브랜치 먹은 상태 )

그상태의 master 가 Logout 브랜치도 먹을수 있는가?

 

사실 fast forward 전략에서
master가 Login 브랜치를 먹을 수 있었던건,

1. "master" 는 수정사항이 없이 그대로 있는 상태
2. "Login" 브랜치만 수정 된 상태

이 조건이 만족 되었기 때문이다.

 

근데 여기선 master가 Login브랜치를 먹는 순간,
master 는 예전의 master 가 아니게 된다. ( 수정사항이 생김 )

 

master브랜치 : "Login먹고 왔어. 다음은 너야!"
Logout브랜치 : "아니 근데.. 누구세요? 머징 안받겠습니다." 

 

=> fast forward 방식 으론 양쪽 다 먹을수 없다

=> 3Way merging 전략을 써야한다. ( 실무에서는 이걸 사용해야 할 경우가 더 많다.카더라. )

1. fast forward 전략 그대로 써서 일단 하나 branch 를 먹는다. (merge)
2. 두번 째 branch 를 먹으려 할 때, 못 알아보니까 다툼이 일어 날 수 밖에 없다. ( conflict )
3. 이 다툼을 잘 이겨 내서 merge 한다.

두번째 branch 도 똑같이 master 브랜치로 이동한후 merge 를 시도한다.

그럼, conflict 가 난다며, 오류를 보여준다.

 

그 부분을 직접 들어가서 수정, 정돈 해 준다.

 

정돈이 끝나면 직접 master 에서 "새롭게 커밋"을 하나 만들어준다. (필수)

 

그럼 그게 결국 두번째 branch 까지 merge 한 master 가 된다.

 

 

conflict 는 나쁜게 아니고, 이용해야할 기능이라고 생각하자.