3.2 Git 브랜치 - 브랜치와 Merge의 기초
브랜치와 Merge의 기초
실제 개발과정에서 겪을 만한 예제를 하나 살펴보자. 브랜치와 Merge는 보통 이런 식으로 진행한다:- 작업 중인 웹사이트가 있다.
- 새로운 이슈를 처리할 새 Branch를 하나 생성.
- 새로 만든 Branch에서 작업 중.
- 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 복원.
- Hotfix 브랜치를 새로 하나 생성.
- 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge.
- 다시 작업하던 브랜치로 옮겨가서 하던 일 진행.
브랜치의 기초
먼저 커밋을 몇 번 했다고 가정하자.
그림 3-10 현재 커밋 히스토리
이슈 관리 시스템에 등록된 53번 이슈를 처리한다고 하면 이 이슈에 집중할 수 있는 브랜치를 새로 하나 만든다. Git은 어떤 이슈 관리 시스템에도 종속돼 있지 않다. 브랜치를 만들면서 Checkout까지 한 번에 하려면
git checkout 명령에 -b라는 옵션을 준다.$ git checkout -b iss53
Switched to a new branch 'iss53'
$ git branch iss53
$ git checkout iss53
그림 3-11 브랜치 포인터를 새로 만듦
iss53 브랜치를 Checkout했기 때문에(즉, HEAD는 iss53 브랜치를 가리킨다) 뭔가 일을 하고 커밋하면 iss53 브랜치가 앞으로 진행한다:
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
그림 3-12 진행 중인 iss53 브랜치
다른 상황을 가정해보자. 만드는 사이트에 문제가 생겨서 즉시 고쳐야 한다. 버그를 해결한 Hotfix에 'iss53'이 섞이는 것을 방지하기 위해 'iss53'와 관련된 코드를 어딘가에 저장해두고 원래 운영 환경의 소스로 복구해야 한다. Git을 사용하면 이런 노력을 들일 필요 없이 그냥 master 브랜치로 옮기면 된다.
그렇지만, 브랜치를 이동하려면 해야 할 일이 있다. 아직 커밋하지 않은 파일이 Checkout할 브랜치와 충돌 나면 브랜치를 변경할 수 없다. 브랜치를 변경할 때에는 워킹 디렉토리를 정리하는 것이 좋다. 이런 문제를 다루는 방법은(주로, Stash이나 커밋 Amend에 대해) 나중에 다룰 것이다. 지금은 작업하던 것을 모두 커밋하고 master 브랜치로 옮긴다:
$ git checkout master
Switched to branch 'master'
hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사용한다:
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix]: created 3a0874c: 'fixed the broken email address'
1 files changed, 0 insertions(+), 1 deletions(-)
그림 3-13 master 브랜치에서 갈라져 나온 hotfix 브랜치
운영 환경에 적용하려면 문제를 제대로 고쳤는지 테스트하고 master 브랜치에 합쳐야 한다.
git merge 명령으로 다음과 같이 한다:$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
README | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
이제 hotfix는 master 브랜치에 포함됐고 운영환경에 적용할 수 있다(그림 3-14).
그림 3-14 Merge 후 hotfix 브랜치와 같은 것을 가리키는 master 브랜치
문제를 급히 해결하고 master 브랜치에 적용하고 나면 다시 일하던 브랜치로 돌아가야 한다. 하지만, 그전에 필요없는 hotfix 브랜치를 삭제한다.
git branch 명령에 -d 옵션을 주고 브랜치를 삭제한다.$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
$ git checkout iss53
Switched to branch 'iss53'
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53]: created ad82d7a: 'finished the new footer [issue 53]'
1 files changed, 1 insertions(+), 0 deletions(-)
그림 3-15 master와 별개로 진행하는 iss53 브랜치
위에서 작업한 hotfix가 iss53 브랜치에 영향을 끼치지 않는다는 점을 이해하는 것이 중요하다.
git merge master 명령으로 master 브랜치를 iss53 브랜치에 Merge하면 iss53 브랜치에 hotfix가 적용된다. 아니면 iss53 브랜치가 master에 Merge할 수 있는 수준이 될 때까지 기다렸다가 Merge하면 hotfix와 iss53가 합쳐진다.Merge의 기초
53번 이슈를 다 구현하고 master 브랜치에 Merge하는 과정을 살펴보자. master 브랜치에 Merge하는 것은 앞서 살펴본 hotfix 브랜치를 Merge하는 것과 비슷하다.git merge 명령으로 합칠 브랜치에서 합쳐질 브랜치를 Merge하면 된다:$ git checkout master
$ git merge iss53
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
그림 3-16 Git은 Merge에 필요한 공통 커밋을 자동으로 찾음
단순히 브랜치 포인터를 최신 커밋으로 옮기는 게 아니라 3-way Merge의 결과를 별도의 커밋으로 만들고 나서 해당 브랜치가 그 커밋을 가리키도록 이동시킨다(그림 3-17). 그래서 이런 커밋은 부모가 여러 개고 Merge 커밋이라고 부른다.
Git은 Merge하는데 필요한 최적의 공통 조상을 자동으로 찾는다. 이런 기능도 Git이 다른 버전 관리 시스템보다 나은 점이다. CVS나 Subversion 같은 버전 관리 시스템은 개발자가 직접 공통 조상을 찾아서 Merge해야 한다. Git은 다른 시스템보다 Merge가 대단히 쉽다.
그림 3-17 Git은 Merge할 때 Merge에 대한 정보가 들어 있는 커밋를 하나 만든다.
iss53 브랜치를 master에 Merge하고 나면 더는 iss53 브랜치가 필요 없다. 다음 명령으로 브랜치를 삭제하고 이슈의 상태를 처리 완료로 표시한다:
$ git branch -d iss53
충돌의 기초
가끔씩 3-way Merge가 실패할 때도 있다. Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge하면 Git은 해당 부분을 Merge하지 못한다. 예를 들어, 53번 이슈와 hotfix가 같은 부분을 수정했다면 Git은 Merge하지 못하고 다음과 같은 충돌(Conflict) 메시지를 출력한다:$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
git status 명령을 이용한다:[master*]$ git status
index.html: needs merge
# On branch master
# Changes not staged for commit:
# (use 'git add <file>...' to update what will be committed)
# (use 'git checkout -- <file>...' to discard changes in working directory)
#
# unmerged: index.html
#
<<<<<<< HEAD:index.html
<div id='footer'>contact : email.support@github.com</div>
=======
<div id='footer'>
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
======= 위쪽의 내용은 HEAD 버전(merge 명령을 실행할 때 작업하던 master 브랜치)의 내용이고 아래쪽은 iss53 브랜치의 내용이다. 충돌을 해결하려면 위쪽이나 아래쪽 내용 중에서 고르거나 새로 작성하여 Merge한다. 다음은 아예 새로 작성하여 충돌을 해결하는 예제다:<div id='footer'>
please contact us at email.support@github.com
</div>
<<<<<<<, =======, >>>>>>> 가 포함된 행을 삭제하였다. 이렇게 충돌한 부분을 해결하고 git add 명령으로 다시 Git에 저장한다. 충돌을 쉽게 해결하기 위해 다른 Merge 도구도 이용할 수 있다. git mergetool 명령으로 실행한다:$ git mergetool
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
Merging the files: index.html
Normal merge conflict for 'index.html':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (opendiff):
opendiff가 실행된다. 기본 도구 말고 사용할 수 있는 다른 Merge 도구도 있는데, 'merge tool candidates' 부분에 보여준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구를 변경하는 방법은 7장에서 다룬다.Merge 도구를 종료하면 Git은 잘 Merge했는지 물어본다. 잘 마쳤다고 입력하면 자동으로
git add가 수행되고 해당 파일이 Staging Area에 저장된다.git status 명령으로 충돌이 해결된 상태인지 다시 한번 확인해볼 수 있다.$ git status
# On branch master
# Changes to be committed:
# (use 'git reset HEAD <file>...' to unstage)
#
# modified: index.html
#
git commit 명령으로 Merge 한 것을 커밋한다. 충돌을 해결하고 Merge할 때에는 커밋 메시지가 아래와 같다.Merge branch 'iss53'
Conflicts:
index.html
#
# It looks like you may be committing a MERGE.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
#
댓글 없음:
댓글 쓰기