Git (Basic) - 3 에서 branch의 개념에 대해 살펴보았습니다.
이제 branch를 실제로 어떻게 사용하는지 포스팅하겠습니다.
1. branch 전환하기
master branch가 아닌 다른 branch에서 작업하고 싶을 때에는, checkout명령어를 사용 합니다.
그리고 아직 commit하지 않은 변경 내용이 Index와 work tree에 남아 있는 채로 checkout하면 그 변경 내용들은 기존 브랜치가 아닌 전환된 branch에서 commit할 수 있습니다.
이때, 변경 내용 중에 전환된 branch에서도 변경되어 있는 경우에는 checkout에 실패할 수 있습니다.
이 경우에는 이전 branch에서 commit하지 않은 변경 내용을 commit하거나 stash를 이용해 이시적으로 변경 내용을 다른 곳에 저장하여 충돌을 피하게 한 뒤 checkout을 해야 합니다.
2. branch 통합하기
topic branch의 작업이 완료되면 integration branch에 병합시켜야합니다. branch integration에는 2가지 방법이 있습니다.
2-1. merge를 이용하는 방법
merge를 사용하면 여러 개의 브랜치를 하나로 모을 수 있습니다.
예를 들어, master branch에서 분기하는 bugfix라는 branch가 있다고 가정하겠습니다.
이 bugfix를 master로 병합할 때
두가지 경우를 고려해야 합니다.
2-1-1. master에 변경이력이 없을 때
이 경우, bugfix는 master의 이력을 모두 포함하고 있기 때문에, master가 단순히 이동하기만 해도 bugfix의 내용을 적용할 수 있습니다.
이 같은 방법을 'fast-forward merge(빨리 감기 병합)'이라고 표현합니다.
2-1-2. master에 변경이력이 있을 때
bugfix branch를 분기한 이후 master에 변경 이력이 생긴 경우에는 master의 변경 이력과 bugfix의 변경 이력을 하나로 통합해야 합니다.
따라서 양쪽의 변경 이력을 가져온 merge commit을 실행해야 합니다.
Tip!
fast-forward merge가 가능한 경우라도 non fast-forward merge 옵션을 지정해 아래와 같이 만들어 낼 수도 있습니다.
non fast-forward merge의 장점은 branch가 그대로 남기 때문에 bugfix에서 변경한 이력 확인 및 branch 관리면에서 더 유용할 수 있습니다.
2-2. rebase를 이용하는 방법
위와 마찬가지로 master에서 분기하는 bugfix가 있다고 가정하겠습니다.
bugfix를 master에rebase 하게 되면 bugfix의 이력이 master 뒤로 이동하게 됩니다.
이 때문에 이력이 하나의 줄기로 이어지게되고 master의 위치를 변경하기 위해서 master에서 bugfux를 fast-forward merge합니다.
3. 왜 rebase가 필요할까?
이를 설명하기 위해서 한가지 상황을 예로 들겠습니다.
topic branch를 만들어 기능 추가를 하다가
master에서 새롭게 버그 수정용 topic을 만들어 기능 추가 작업과 별개로 작업을 진행하고 있었습니다.
버그 수정을 완료해 master에 병합해 둔 상태가 되었습니다.
그리고 다시 기능 추가 branch로 돌아와 수정을 하는데 commit X를 적용한 소스코드가 commit O에도 적용해야만 하는 상황이 발생했습니다.
이 때, rebase를 이용해 쉽게 원하는 작업을 진행할 수 있습니다.
