git branch & merge

브랜치 작업을 하거나 충돌날 때마다 도움을 요청하는 중생들을 줄이고자, git 세미나를 준비하면서 정리한 내용들이다.

* 목표

- 쫄지말고 브랜치(branch) 사용하기.

- 충돌(conflict)이 나더라도 쫄지 않기.

(기본적인 push, pull 정도는 할 줄 안다는 가정하에 불필요한 내용은 생략한다.)

1. 우리는 이럴 때 branch 를 사용한다.

다음 케이스를 보자.

master 브랜치 하나만 가지고 있으면서 이 작업물로 운영서버에 배포를 한다.

이 프로젝트에 [기능] 추가 요청이 들어왔고 팀원들과 협업이 필요하다.

협업이 필요하기 때문에 원격 저장소에 소스를 공유해야 한다.

기능 추가 작업중에 심각한 [버그] 를 발견하여 수정하고 다시 배포를 해야 한다면, 아직 완료되지 않은 [기능] 추가 작업이 같이 배포되어 버린다.

이를 방지하기 위해 필요한 것이 바로 branch 이다.

2. branch 란?

현재 브랜치(예를 들어 master) 에서 해오던 작업은 branch 를 추가하는 순간 별도의 공간에서 추가적으로 개발할 수 있다.

branch 는 이름 그대로 나뭇가지 처럼 작업을 분리시키는 것이다.

master 와 iss53 이라는 브랜치가 있다면 master 에서 작업하는 내용은 iss53 에 영향을 미치지 않으며, iss53 에서 작업하는 내용 역시 master 에 영향을 미치지 않는다.

위 케이스에서 [기능] 추가 작업시 iss53 이라는 브랜치를 새로 생성해서 작업한다면,

또 [버그] 수정 역시 hotfix 라는 브랜치를 새로 생성해서 작업한다면, master 에서 bugfix 를 merge 하고 배포하면 끝이다.

다시 iss53 브랜치를 checkout 하여 [기능] 추가 작업을 계속 하면 된다.

3. merge 란?

branch 가 작업을 분리시키는 명령이라면, 반대로 분리한 작업을 다시 합쳐주는 명령이 바로 merge 이다.

우리는 이미 pull 을 수도 없이 사용하면서 자동 merge 를 사용해 왔다. (pull 명령은 fetch + merge 를 한번에 실행해 주는 명령이다.)

master 브랜치에서 git merge hotfix 명령으로 수정된 버그를 해결하고, git merge testing 명령으로 기능까지 추가한다면,

master 브랜치는 최신 상태의 소스가 되고 배포할 준비가 된다.

branch 와 merge 는 이게 끝이다.

이제 실제로 위 케이스를 실행해 보자.

최종적으로 위와 유사한 결과를 도출할 수 있어야 한다.

[기능] 추가 요청에 대한 iss53 이라는 브랜치 생성.

$ git checkout -b iss53

위 명령은 아래 두개의 명령을 한번해 실행해 줌.

$ git branch iss53
$ git checkout iss53

작업 및 커밋진행

$ git commit -m 'description'

도중에 [버그] 수정 요청에 대한 hotfix 라는 브랜치 생성.

master 에 기반한 브랜치를 생성해야 하므로 master 브랜치를 이동하여 브랜치를 생성.

$ git checkout master
$ git checkout -b hotfix

버그를 수정한 후 커밋을 진행.

$ git commit -m 'description'

수정한 버그를 master 에 합치기 위해 master 브랜치로 이동하여 merge 실행

$ git checkout master
$ git merge hotfix

master 브랜치는 hotfix 브랜치를 생성한 이후에 커밋을 진행하고 있지 않았으므로 단순히 브랜치 포인터만 hotfix 의 최신 커밋으로 이동함. (fast-forward 방식)

다시 iss53 으로 이동하여 [기능] 추가 작업 마무리 하고 커밋하고 master 와 합치기 위해 merge 실행.

$ git checkout iss53
$ git commit -m 'description'
$ git checkout master
$ git merge iss53

master 브랜치는 iss53 브랜치를 생성한(조상) 이후에 커밋이 진행되었으므로 그림처럼 두개의 브랜치가 합쳐지는 3-way merge 처리.

3-way merge 의 결과로 별도의 커밋이 만들어진다.

추가적으로 브랜치를 변경할 때는 기존의 staged 를 깨끗하게 정리하는 것이 좋다. 

commit 이나 staged 를 사용하여 충돌을 체크 및 예방한다.