Critical!
Fast Forward Merges
Fast Forward 병합은 특별한 케이스로 모든 병합이 이런 방법으로 작동하는 것은 아니다. 브랜치는 단순히 브랜치 포인터에 의해 정의된다는 것을 기억한다면, Fast forward 병합은 단순히 master 브랜치의 브랜치 포인터가 bugfix 브랜치 포인터가 가르키는 커밋으로 포인터가 이동하는 것을 의미한다. 주의해야할 점은 이러한 병합은 영원한 동기화를 의미하지는 않는다.
** git branch -v-> 브랜치의 마지막 커밋 이름과 커밋 메시지를 볼 수 있다.
Git Merge & Merge Commits
프로젝트를 진행 중에 독립된 feature 브랜치에서 작업을 하다가 어느 시점에서 우리가 하고 있는 작업의 일부를 결합할 필요가 있다. 이 때 master 브랜치는 source of tree로 생각해서 master 브랜치에서는 실험적인 것(코드를 망칠 수 있는 것)을 진행하지 않고, 따로 feature 브랜치를 만들어서 작업을 진행한다. 만약 feature 브랜치에서 작업한 것들이 적절하다고 판단되면, master 브랜치에 해당 작업을 병합(merge)한다.
이 때 병합에 관해 혼동할 수 있는 몇가지가 있다. 첫째는 병합을 할때에는 특정 커밋이 아니라 브랜치를 병합한다. 그래서 커밋과 커밋을 결합하는 것이 아니다. 그리고 두 번째는, 항상 현재 HEAD 브랜치에 병합한다. 즉 현재 우리가 있는 위치에 병합한다.
이러한 예제를 생각해보자. 우선 master 와 bugfix라는 브랜치가 있다고 생각해보자.
bugfix의 브랜치를 master 브랜치에 병합해야된다고 생각해보자.
1.여기서 병합을 하기 위해서는 우선 우리가 병합하길 원하는 브랜치(branch you want to merge the changes into)로 이동해야한다.
2. 두 번째로 git merge bugfix를 사용하는 것인데, 이렇게 하면 bugfix에 있는 브랜치의 변화(changes from a specific
branch=bugfix)를 현재 브랜치로 병합시킨다(master 브랜치). 그렇게 되면 브랜치 레퍼런스가 bugfix가 가리키고 있던, 커밋을 가리키게 된다. 결과는 아래와 같다.
실제 결과는 다음과 같이 변한다. 아래의 그림을 보면 잘 이해가 된다.
이것을 Fast-Forward 병합이라고 하는데, 단순히 Master 브랜치(의 reference pointer)가 Bugfix의 커밋을 따라잡는 것이기 때문이다.
즉 2개의 브랜치가 있고 브랜치 중 하나(bugfix)는 첫번째 브랜치(master 브랜치)가 갖고 있지 않은 추가 커밋을 가지고 있으면, git switch master git merge bugfix를 하면, fast-forward 병합이 일어난다.
그렇지만 모든 병합이 이러한 모습은 아니다. 예를 들어서 2명이 한 팀인 곳에서 일하고 있는데, 프로젝트의 master 브랜치가 있고, bugfix라는 새로운 브랜치를 만들었다고 생각해보자. 그리고 작업을 한후 그 작업에 만족해서 그것을 master 브랜치에 병합하고자 한다. 그때 다른 사람이 이미 master 브랜치에 일부 작업을 커밋한 것을 알게 되었다. 그림으로 나타내면 다음과 같다.
이렇게 되면 bugfix에는 없는 commit이 master 브랜치에 있게 되고, 이렇게 되면 fast forward merge가 불가능한 상황이 된다. 즉 master 브랜치에 있는 정보가 bugfix에는 없고, bugfix 브랜치에 있는 정보가 master 브랜치에는 없는 상황이 된다. 이런 상황은 깃이 자동적으로 브랜치를 병합하지 못할 수도 있다. 만약에 master 브랜치에서 나의 동료가 파일의 59번째 라인을 바꾸었고 나도 bugfix 브랜치에서 같은 라인을 편집했다면 충돌에서 누가 이길지 생각을 해봐야 한다.(충돌 상황)
그러나 지금은 빨리 감기 병합이 아니고 충돌 상황도 발생하지 않는 경우를 보여주고자 한다.
위의 그림과 같이 Merge commit이 생기면서 병합이 진행된다. 이때 Merge commit은 두개의 부모 커밋을 갖게 된다. 아래는 실제 git kraken에서 확인한 병합 과정이다.
그 다음 master 브랜치에서 git merge ABBA를 진행하면 다음과 같은 메시지가 뜬다.
이것은 새로운 커밋(merge commit)이 생겼다고 말해주고, 커밋 메시지를 작성할 수 있게 해준다.
Merge를 진행하면 다음과 같은 변경사항이 나타난다.
Resolving Merge Conflicts
예를 들어 한 브랜치에서 누군가가 파일을 수정했고, 병합하고 있는 두 번째 브랜치에서 누군가가 동일한 파일을 삭제 했다고 하거나 또는 만약 한 브랜치에서 어떤 파일의 77번째 라인을 편집하고, 누군가는 다른 브랜치에서 같은 작업을 한다면 깃은 자동적으로 병합하는 방법을 알지 못한다.
Git merge를 실행할 때, 충돌이 생기면 다음과 같은 메시지가 뜬다. Conflict(content) Merge conflict in blah.txt ... 그리고 그 문제가 되는 파일을 열면 아래와 같은 것(conflict markers)을 볼 수 있다.
<<<<<<<HEAD
I have 2 cats
I also have chickens
=======
I used to have a dog :(
>>>>>>>bug-fix
<<<<<HEAD 와 ======의 사이 부분은 현재 HEAD 가 가르키고 있는 브랜치에서 가져올 컨텐츠이고 그 아래 부분은 bug-fix 브랜치에서 가져올 컨텐츠이다.
<해결방법>
1.충돌이 발생한 파일을 연다.
2.충돌을 어떻게 해결할지 파악 후 파일을 편집
3.conflict markers를 제거한다.
4.커밋한다.
Important
Nice to Have
Using VSCode To Resolve Conflicts
상단에 Accept Current Change Accept Incoming Change Accept Both Changes Compare Changes 가 있다. 하나하나 수정할 수도 있지만, 위의 옵션을 선택할 수 있다.
