Pro git 독학 일지 6장 - Git 브랜치(2)

Pro git 독학 일지 6장 - Git 브랜치(2)

 

브랜치 관리

 

git branch 명령은 단순히 브랜치를 만들고 삭제하는 것이 아니다.

아무런 옵션 없이 실행하면 브랜치의 목록을 보여준다.

 

 

* 기호가 붙어있는 master 브랜치는 현재 Checkout해서 작업하는 브랜치를 나타낸다.

즉, 지금 수정한 내용을 커밋하면 master 브랜치에 커밋되고 포인터가 앞으로 한단계 나아간다.

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

 

 

각 브랜치가 지금 어떤 상태인지 확인하기에 좋은 옵션도 있다.

현재 Checkout한 브랜치를 기준으로 --merged와 --no-merged 옵션을 사용하여

Merge된 브랜치인지 그렇지 않은지 필터링해볼 수 있다.

 

 

iss53 브랜치는 앞에서 이미 Merge했기 때문에 목록에 나타난다.

* 기호가 붙어있지 않은 브랜치는 git branch -d 명령으로 삭제해도 되는 브랜치다.

이미 다른 브랜치와 Merge했기 때문에 삭제해도 정보를 잃지 않는다.

 

반대로 현재 Checkout한 브랜치에 Merge하지 않은 브랜치를 살펴보려면 git branch --no-merged 명령을 사용한다.

 

 

위에는 없었던 다른 브랜치가 보인다.

아직 Merge하지 않은 커밋을 담고 있기 때문에 git branch -d 명령으로 삭제되지 않는다.

 

 

Merge하지 않은 브랜치를 강제로 삭제하려면 -D 옵션으로 삭제한다.

 

 

브랜치 워크플로

 

브랜치가 유용한 몇 가지 워크플로를 살펴본다.

 

 

Long-Running 브랜치

 

Git은 꼼꼼하게 3-way Merge를 사용하기 때문에 장기간에 걸쳐서 한 브랜치를 다른 브랜치와 여러 번 Merge하는 것이 쉬운 편이다.

그래서 개발 과정에서 필요한 용도에 따라 브랜치를 만들어 두고 계속 사용할 수 있다.

그리고 정기적으로 브랜치를 다른 브랜치로 Merge한다.

 

이런 접근법에 따라서 Git 개발자가 많이 선호하는 워크플로가 하나 있다.

배포했거나 배포할 코드만 master 브랜치에 Merge해서 안정 버전의 코드만 master 브랜치에 둔다.

개발을 진행하고 안정화하는 브랜치는 develop이나 next라는 이름으로 추가로 만들어 사용한다.

이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다.

테스트를 거쳐서 안정적이라고 판단되면 master 브랜치에 Merge 한다.

토픽 브랜치(앞서 살펴본 iss53 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데,

해당 토픽을 처리하고 테스트해서 버그도 없고 안정적이면 그 때 Merge한다.

 

사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다.

커밋 포인터를 만들고 수정하고 분리하고 합치는지에 때한 것이다.

개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다.

 

 

실험실에서 충분히 테스트하고 실전에 배치하는 과정으로 보면 이해하기 쉽다.

 

 

코드를 여러 단계로 나누어 안정성을 높여가며 운영할 수 있다. 

프로젝트 규모가 크면 proposed 혹은 pu(proposed updates)라는 이름의 브랜치를 만들고

next나 master 브랜치에 아직 Merge할 준비가 되지 않은 것을 일단 Merge 시킨다.

중요한 개념은 브랜치를 이용해 여러 단계에 걸쳐서 안정화해 나아가면서 충분히 안정화가 됐을 때 안정 브랜치로 Merge한다는 점이다.

다시 말해서 Long-Running 브랜치는 정말 유용하다.

특히 규모가 크고 복잡한 프로젝트일 수록 그 유용성이 반짝반짝 빛난다.

 

 

토픽 브랜치

 

토픽 브랜치는 프로젝트 크기에 상관없이 유용하다.

토픽 브랜치는 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치다.

다른 버전 관리 시스템에서는 이런 브랜치를 본 적이 없을 것이다.

Git에서는 매우 일상적을 브랜치를 만들고 Merge하고 삭제한다.

 

앞서 사용한 iss53이나 hotfix브랜치가 토픽 브랜치다.

우리는 브랜치를 새로 만들고 어느 정도 커밋하고 나서 다시 master 브랜치에 Merge하고 브랜치 삭제도 해보았다.

보통 주제별로 브랜치를 만들고 각각은 독립돼있기 때문에 매우 쉽게 컨텍스트 사이를 옮겨다닐 수 있다.

묶음별로 나눠서 일하면 내용별로 검토하기에도, 테스트하기에도 더 편하다.

각 작업을 하루든 한 달이든 유지하다가 master 브랜치에 Merge할 시점이 되면 순서에 관계없이 그 때 Merge하면 된다.

 

master 브랜치를 checkout한 상태에서 어떤 작업을 한다고 해보자.

한 이슈를 처리하기 위해서 iss91 브랜치를 만들고 해당 작업을 한다.

같은 이슈를 다른 방법으로 해결해보고 싶을 때도 있다.

iss91v2 브랜치를 만들고 다른 방법을 시도해본다.

확신할 수 없는 아이디어를 적용해보기 위해 다시 master 브랜치로 되돌아가서 dumbidea 브랜치를 하나 더 만든다.

지금까지 말했던 커밋 히스토리는 아래 그림과 같다.

 

 

이슈를 처리했던 방법 중 두 번째 방법인 iss91v2 브랜치가 괜찮아서 적용하기로 결정했다.

그리고 아이디어를 확신할 수 없었던 dumbidea 브랜치를 다른 개발자에게 보여줬더니 썩 괜찮다는 반응을 얻었다.

iss91 브랜치는 버리고 다른 두 브랜치를 Merge하면 아래 그림과 같이 된다.

 

 

분산 환경에서의 Git에서 프로젝트를 Git으로 관리할 때 브랜치를 이용하여 만들 수 있는 여러 워크플로에 대해 살펴본다.

관련 부분을 살펴보면 프로젝트에 어떤 형태로 응용할 수 있을지 감이 올 것이다.

 

지금까지 한 작업은 전부 로컬에서만 처리한다는 것을 꼭 기억하자.

로컬 저장소에서만 브랜치를 만들고 Merge했으며 서버와 통신을 주고받는 일은 없었다.