🌈 Chapter 3: Git 브랜치

🦄 브랜치란 무엇인가

🐣 새 브랜치 생성하기

git branch 명령으로 testing 브랜치 생성

> git branch testing

새로 만든 브랜치도 지금 작업하고 있던 마지막 커밋을 가리킨다.

지금 작업 중이 브랜치가 무엇인지 Git은 어떻게 파악할까. 다른 버전 관리 시스템과는 달리 Git은 HEAD라는 특별한 포인터가 있다. 이 포인터는 지금 작업하는 로컬 브랜치를 가리킨다. 브랜치를 새로 만들었지만, Git은 아직 master 브랜치를 가리키고 있다. git branch 명령은 브랜치를 만들기만 하고 브랜치를 옮기지 않는다.

🐣 브랜치 이동하기

git checkout 명령으로 다른 브랜치로 이동할 수 있다. 한번 testing 브랜치로 바꿔보자.

> git checkout testing

이렇게 하면 HEAD는 testing 브랜치를 가리킨다.

앞으로 커밋을 하면 다른 브랜치의 작업들과 별개로 진행되기 때문에 testing 브랜치에서 임시로 작업하고 원래 master 브랜치로 돌아와서 하던 일을 계속할 수 있다.

브랜치를 이동하면 워킹 디렉터리의 파일이 변경된다는 점을 기억해두어야 한다. 이전에 작업했던 브랜치로 이동하면 워킹 디렉터리의 파일은 그 브랜치에서 가장 마지막으로 했던 작업 내용으로 변경된다. 파일 변경 시 문제가 있어 브랜치를 이동시키는 게 불가능한 경우 Git은 브랜치 이동 명령을 수행하지 않는다.

프로젝트 히스토리는 분리돼 진행한다. 우리는 브랜치를 하나 만들어 그 브랜치에서 일을 좀 하고, 다시 원래 브랜치로 되돌아와서 다른 일을 했다. 두 작업 내용은 서로 독립적으로 각 브랜치에 존재한다. 커밋 사이를 자유롭게 이동하다가 때가 되면 두 브랜치를 Merge한다.

실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽다. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을 하나 만드는 것에 불과하다.
커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge할 떄 어디서부터 합쳐야 하는지 안다.

🦄 브랜치와 Merge의 기초

1. 작업 중인 웹사이트가 있다.
2. 새로운 이슈를 처리할 새 Branch를 하나 생성한다.
3. 새로 만드는 Branch에서 작업을 진행한다.

이때 중요한 문제가 생겨서 그것을 해결하는 Hotfix를 먼저 만들어야 한다. 그러면 아래와 같이 할 수 있다.

1. 새로운 이슈를 처리하기 이전의 운영 브랜치로 이동한다.
2. Hotfix 브랜치를 새로 하나 생성한다.
3. 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge한다.
4. 다시 작업하던 브랜치로 옮겨가서 하던 일을 진행한다.

🐣 브랜치의 기초

브랜치를 이동하려면 해야 할 일이 있다. 아직 커밋하지 않은 파일이 Checkout할 브랜치와 충돌 나면 브랜치를 변경할 수 없다. 브랜치를 변경할 때에는 워킹 디렉터리를 정리하는 것이 좋다. 작업하던 것을 모두 커밋하고 master 브랜치로 옮긴다.

Merge할 브랜치가 가리키는 커밋이 현 브랜치 커밋의 Upstream 브랜치이기 때문에 master 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. 이런 Merge 방식을 Fast Forward라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge할 때 B 브랜치가 A 브랜치 이후 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다.

더 이상 필요없는 hotfix 브랜치는 삭제한다. git branch 명령어에 -d 옵션을 주고 브랜치를 삭제한다.

> git branch -d hotfix

🐣 Merge의 기초

hotfix를 Merge했을 때와 메시지가 다르다. 현재 브랜치가 가리키는 커밋이 Merge할 브랜치의 조상이 아니므로 Git은 Fast-forward로 Merge하지 않는다. 이 경우에는 Git은 각 브랜치가 가리키는 커밋 두 개와 공통 조상 하나를 사용하여 3-way Merge를 한다.

단순히 브랜치 포인터를 최신 커밋으로 옮기는 게 아니라 3-way Merge의 결과를 별도의 커밋으로 만들고 나서 해당 브랜치가 그 커밋을 가리키도록 이동시킨다. 그래서 이런 커밋은 부모가 여러 개고 Merge 커밋이라고 부른다.

Git은 Merge하는데 필요한 최적의 공통 조상을 자동으로 찾는다.

🐣 충돌의 기초

가끔 3-way Merge가 실패할 때도 있다. Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge하면 Git은 해당 부분을 Merge하지 못한다. 이럴 경우 충돌(Conflict) 메시지를 출력한다.

Git이 자동으로 Merge하지 못했기에 새 커밋이 생기지 않는다. 변경사항의 충돌을 개발자가 해결하지 않는 한 Merge 과정을 진행할 수 없다. Merge 충돌이 일어났을 때 Git이 어떤 파일을 Merge할 수 없었는지 살펴보려면 git status 명령을 이용한다.

충돌이 일어난 파일은 unmerged 상태로 표시된다. Git은 충돌이 난 부분을 표준 형식에 따라 표시해준다. 그러면 개발자는 해당 부분을 수동으로 해결한다. 이렇게 충돌한 부분을 해결하고 git add 명령으로 다시 Git에 저장한다.

🦄 브랜치 관리

git branch 명령은 단순히 브랜치를 만들고 삭제하는 것이 아니다. 아무런 옵션 없이 실행하면 브랜치의 목록을 보여준다.

git branch -v 명령을 실행하면 브랜치마다 마지막 커밋 메시지도 함꼐 보여준다.

각 브랜치가 지금 어떤 상태인지 확인하기에 좋은 옵션도 있다. 현재 Checkout 한 브랜치를 기준으로 --merged와 --no--merged 옵션을 사용하며 Merge된 브랜치인지 그렇지 않은 브랜치인지 필터링해 볼 수 있다. git branch --merged 명령어로 이미 Merge한 브랜치 목록을 확인한다.

🦄 브랜치 워크플로

🐣 Long-Running 브랜치

배포했거나 배포할 코드만 master 브랜치에 Merge해서 안정 버전의 코드만 master 브랜치에 둔다. 개발을 진행하고 안정화하는 브랜치는 develop이나 next라는 이름으로 추가로 만들어 사용한다. 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다. 테스트를 거쳐서 안정적이라고 판단되면 master 브랜치에 Merge한다. 토픽 브랜치에도 적용할 수 있는데, 해당 토픽을 처리하고 테스트해서 버그도 없고 안정적이면 그때 Merge한다.

사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다. 커밋 포인터를 만들고 수정하고 분리하고 합치는지에 대한 것이다. 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다.

코드를 여러 단계로 나누어 안정성을 높여가며 운영할 수 있다. 프로젝트 규모가 크면 proposed 혹은 pu(proposed updates)라는 이름의 브랜치를 만들고 next나 mater 브랜치에서 아직 Merge할 준비가 되지 않은 것을 일단 Merge시킨다. 중요한 개념은 브랜치를 이용해 여러 단계에 걸쳐서 안정화해 나아가면서 충분히 안정화가 됐을 때 안정 브랜치로 Merge한다는 점이다. 다시 말해서 Long-Running의 브랜치가 여러 개일 필요은 없지만 정말 유용하 할 수 있다

🐣 토픽 브랜치

토픽 브랜치는 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치다. 보통 주제별로 브랜치를 만들고, 각각은 독립돼 있기 때문에 매우 쉽게 컨텍스트 사이를 옮겨 다닐 수 있다. 묶음 별로 나눠서 일하면 내용별로 검토하기에도, 테스트하기에도 더 편한다. 각 작업을 하루든 한 달이든 유지하다가 master 브랜치에 Merge할 시점이 되면 순서와 관계없이 그 때 Merge하면 된다.

🦄 리모트 브랜치

리모트 Refs는 리모트 저장소에 있는 포인터인 레퍼런스다. 리모트 저장소에 있는 브랜치, 태그 등등을 의미한다. git ls-remote (remote) 명령으로 모든 리모트 Refs를 조회할 수 있다. git remote show (remote) 명령은 모든 리모트 브랜치와 그 정보를 보여준다. 리모트 Refs가 있지만 보통 리모트 트래킹 브랜치를 사용한다.

리모트 트래킹 브랜치는 리모트 브랜치를 추적하는 브랜치다. 이 브랜치는 로컬에 있지만 움직일 수 없다. 리모트 서버에 연결할 때마다 리모트 브랜치에 따라서 자동으로 움직일 뿐이다.

리모트 브랜치의 이름은 (remote)/(branch) 형식으로 되어 있다. (ex. origin/master) origin으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 가리키는 포인터를 만든다. 이 포인터는 origin/mater라고 부르고 멋대로 조종할 수 없다. 그리고 Git은 로컬의 master 브랜치가 origin/mater를 가리키게 한다. 이제 master 브랜치에서 작업을 시작할 수 있다.

리모트 서버로부터 저장소 정보를 동기화하려면 git fetch origin 명령을 사용한다. 명령을 실행하면 우선 origin 서버의 주소 정보를 찾아서, 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.

🐣 Push하기

로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 Push해야 한다. 로컬 저장소의 브랜치는 자동으로 리모트 저장소로 전송되지 않는다. 명시적으로 브랜치를 Push해야 정보가 전송된다. 따라서 리모트 저장소에 전송하지 않고 로컬 브랜치에만 두는 비공개 브랜치를 만들 수 있다. 또 다른 사람과 협업하기 위해 토픽 브랜치만 전송할 수도 있다.

> git push (remote) (branch) 

Fetch 명령으로 리모트 트래킹 브랜치를 내려 받는다고 해서 로컬 저장소에 수정할 수 있는 브랜치가 새로 생기는 것이 아니다. 다시 말해서 브랜치가 생기는 것이 아니라 그저 수정 못하는 origin 브랜치 포인터가 생기는 것이다.

🐣 브랜치 추적

리모트 트래킹 브랜치를 로컬 브랜치로 Checkout하면 자동으로 트래킹 브랜치가 만들어진다. 트래킹 브랜치는 리모트 브랜치와 직접적인 연결고리가 있는 로컬 브랜치이다. 트래킹 브랜치에서 git pull 명령을 내리면 리모트 저장소로부터 데이터를 내려받아 연결된 리모트 브랜치와 자동으로 Merge한다.

서버로부터 저장소를 Clone을 하면 Git은 자동으로 master 브랜치를 origin/master 브랜치의 트래킹 브랜치로 만든다. 트래킹 브랜치를 직접 만들 수 있는데 리모트를 origin이 아닌 다른 리모트로 할 수도 있고, 브랜치도 master가 아닌 다른 브랜치로 추적할 수 있다.

리모트 브랜치와 다른 이름으로 브랜치를 만들려면 로컬 브랜치의 이름을 아래와 같이 다르게 지정한다.

> git checkout -b sf origin/serverfix

이제 sf 브랜치에서 Push나 Pull하면 자동으로 origin/serverfix로 데이터를 보내거나 가져온다.

추적 브랜치가 현재 어떻게 설정되어 있는지 확인하려면 git branch 명령에 -vv 옵션을 더한다. 이 명령을 실행하면 로컬 브랜치 목록과 로컬 브랜치가 추적하고 있는 리모트 브랜치도 함께 보여준다. 게다가 로컬 브랜치가 앞서가는지 뒤처지는지에 대한 내용도 보여준다.

> git branch -vv

🐣 Pull하기

git fetch 명령을 실행하면 서버에는 존재하지만, 로컬에는 아직 없는 데이터를 받아와서 저장한다. 이때 워킹 디렉터리의 파일 내용은 변경되지 않고 그대로 남는다. 서버로부터 데이터를 가져와서 저장해두고 사용자가 Merge하도록 준비만 해둔다.

간단히 말하면 git pull 명령은 대부분 git fetch명령을 실행하고 나서 자동으로 git merge 명령을 수행하는 것뿐이다.

일반적으로 fetch와 merge 명령을 명시적으로 사용하는 것이 pull 명령으로 한 번에 두 작업을 하는 것보다 낫다.

🐣 리모트 브랜치 삭제

git push 명령에 --delete 옵션을 사용하여 리모트 브랜치를 삭제할 수 있다. serverfix라는 리모트 브랜치를 삭제하려면 아래와 같이 실행한다.

> git push origin --delete serverfix

위 명령을 실행하면 서버에서 브랜치 하나가 사라진다. 서버에서 가비지 컬렉터가 동작하지 않는 한 데이터는 사라지지 않기 때문에 종종 의도치 않게 삭제한 경우에도 커밋한 데이터를 살릴 수 있다.

🦄 Rebase하기

Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 두 가지다. 하나는 Merge이고 다른 하나는 Rebase다.

🐣 Rebase의 기초

rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.

실제로 일어나는 일을 설명하자면 일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장해 놓는다. Rebase할 브랜치가 합칠 브랜치가 가리키는 커밋을 가리키게 하고 아까 저장해 놓았던 변경사항을 차례대로 적용한다. 그러고 나서 master 브랜치를 Fast-forward한다.

Merge든 Rebase든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만, Rebase가 좀 더 깨끗한 히스토리를 만든다. Rebase한 브랜치의 Log를 살펴보면 히스토리가 선형이다. 일을 병렬로 동시에 진행해도 Rebase하고 나면 모든 작업이 차례대로 수행된 것처럼 보인다.

Rebase는 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다. 아마 이렇게 Rebase하는 리모트 브랜치는 직접 관리하는 것이 아니라 그냥 참여하는 브랜치일 것이다. 메인 프로젝트에 Patch를 보낼 준비가 되면 하는 것이 Rebase니까 브랜치에서 하던 일을 완전히 마치고 origin/master로 Rebase한다. 이렇게 Rebase하고 나면 프로젝트 관리자는 어떠한 통합작업도 필요 없다. 그냥 mater 브랜치를 Fast-forward하면 된다.

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다. Rebase의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고 Merge의 경우는 두 브랜치의 최종결과만 가지고 합친다.

🐣 Rebase의 위험성

Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다.

이미 공개 저장소에 Push한 커밋을 Rebase하지 말라

이 지침만 지키면 Rebase를 하는 데 문제 될 게 없다. 하지만 이 주의사항을 지키지 않으면 사람들에게 욕을 먹을 것이다.
Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push하고 동료 중 누군가 그 커밋을 Pull해서 작업을 한다고하자. 그런데 그 커밋을 git rebase로 바꿔서 Push해버리면 동료가 다시 Push했을 때 동료는 다시 Merge해야 한다. 그리고 동료가 다시 Merge한 내용을 Pull하면 내 코드는 정말 엉망이 된다.

🐣 Rebase한 것을 다시 Rebase하기

어떤 팀원이 강제로 내가 한 일을 덮어썼다고 하자. 그러면 내가 했던 일이 무엇이고 덮어쓴 내용이 무엇인지 알아내야 한다.

커밋 SHA 체크섬 외에도 Git은 커밋에 Patch할 내용으로 SHA 체크섬을 한 번 더 구한다. 이 값은 patch-id라고 한다.
덮어쓴 커밋을 받아서 그 커밋을 기준으로 Rebase할 때 Git은 원래 누가 작성한 코드인지 잘 찾아낸다. 그래서 Patch가 원래대로 잘 적용된다.

git pull 명령을 실행할 때 옵션을 붙여서 git pull --rebase로 Rebase할 수도 있다. git pull 명령을 실행할 때 기본적으로 --rebase 옵션이 적용되도록 pull.rebase 설정을 추가할 수 있다. git config --global pull.rebase true 명령으로 추가한다.

Push하기 전에 정리하려고 Rebase하는 것은 괜찮다. 또 절대 공개하지 않고 혼자 Rebase하는 경우도 괜찮다. 하지만 이미 공개하여 사람들이 사용하는 커밋을 Rebase하면 틀림없이 문제가 생긴다. 나중에 후회하지 말고 git pull --rebase로 문제를 미리 방지할 수 있따는 것을 같이 작ㅇ업하는 동료와 모두 함께 공유하기 바란다.

🐣 Rebase vs. Merge

Merge와 Rebase 둘 중 무엇을 쓰는 게 좋지? 이 질문에 대한 답을 찾기 전에 히스토리의 의미에 대해서 잠깐 다시 생각해보자.

히스토리를 보는 관점 중에 하나는 작업한 내용의 기록으로 보는 것이다. 작업 내용을 기록한 문서이고, 각 기록은 각각 의미를 가지며, 변경할 수 없다. 이런 관점에서 커밋 히스토리를 변경한다는 것은 역사를 부정하는 꼴이 된다. 언제 무슨 일이 있었는지 기록에 대해 거짓말을 하게 되는 것이다.

히스토리를 프로젝트가 어떻게 진행되었나에 대한 이야기로도 볼 수 있다. 소프트웨어를 주의 깊게 편집하는 방법에 메뉴얼이나 세세한 작업 내용을 초벌부터 공개하고 싶지 않을 수 있다. 나중에 다른 사람에게 들려주기 좋도록 Rebase나 filter-branch 같은 도구로 프로젝트의 진행 이야기를 다듬으면 좋다.

Merge나 Rebase 중 무엇이 나으냐는 질문은 다시 생각해봐도 답이 그리 간단치 않다. Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을 수 있지만, 모든 팀과 모든 이가 처한 상황은 모두 다르다. 이 둘을 어떻게 쓸지는 각자의 상황과 각자의 판단에 달렸다.

일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase할 수도 있지만, 리모트 등 어딘가 밖으로 Push로 내보낸 커밋에 대해서는 절대 Rebase하지 말아야 한다.