Git Branch 전략

다음의 내용은 개발실 內 교육자료로 사용되며, Git Branch 전략 사용 모델은 기본적인 브랜치 스탠다드 모델 기준으로 작성한다.

또한 다음 소개될 모델은 http://nvie.com/posts/a-successful-git-branching-model/ 제공되는 기본적이 공식 모델을 내용으로 인용 하였다.

소개될 모델은 단순히 소프트웨어 개발 프로세스를 구성하고 개발 구성원 모두가 동일한 지침과 규정에 따르기 위하여 만들었다.

개발 구성원 전원은 Remote 에 push/pull 할 수 있지만, 기본적으로 pull 을 먼저 진행하는것을 원칙으로 한다.

왜 사용하게 되었는가?

• 각 각의 기능이 순차적으로 개발되거나 하나의 기능이 완료된 사항에서, 다른 기능이 개발 및 유지보수 운용이 복잡하며 어렵다.

• 차기 버전을 개발하는 도중에 운영중인 이슈 또는 장애로 인하여 현재 버전의 긴급 패치가 발생되면 개발 충돌이 빈번하게 발생한다. 

순차적으로 개발 되지 않는 이유는

요구사하에 대한 제대로 기획되지 못한 경우, 또는 제대로 된 기획이나 요구사항이 있더라도 프로젝트를 진행하는 과정에서

빈번하게 변경이 발생되고 때로는 정책적인 이슈로 인해서 특정 기능의 개발이 지연 되는 경우가 대부분이다.

또한 대부분은 A 라는 기능을 개발하고 있는 중 B, C, D...  등 다른 기능을 병행 해야 할 경우가 많이 발생 된다. 

브랜치 종류

기본적으로 우리는 5가지 브랜치로 개발이 진행 된다.

항상 유지되는 주 메인 브랜치(Master / Develop)이 있으며, 일정 기간동안 만 유지 되는 보조 브랜치(Feature / Release / Hotfix)가 있다.

1. Master  : 언제나 상용서버에 배포가 가능할 수 있는 Branch
2. Develop : 기능 개발 및 배포 버전을 준비하고 개발자들 간 공유 pull/push 해야 하는 Branch
3. Release : 단기간 배포 버전을 출시해야 하는 Branch
4. Feature : 장기간 기능을 개발하는 Branch
5. Hotfix :  배포된 이후 긴급 또는 버그를 수정하는 Branch

Main Branch 

개발자는 master 브랜치와 develop 브랜치를 병행으로 유지한다.

먼저 배포했거나 곧 배포할(production-ready) 코드는 origin/master에 두고 관리한다.

그리고 다음에 배포할 것을 개발하는 코드는 origin/develop에 두고 관리한다.

이 브랜치를 "통합 브랜치(integration branch)"라고 부르기도 하는데, 이 브랜치를 자동으로 매일 빌드하는데 사용한다.

develop branch의 코드가 안정되고 배포할 준비가 되면 곧 master로 merge하고 배포 버전으로 태그를 단다.

즉, 정의한 대로 master로 merge하는 것은 새 버전을 배포하는 것을 의미한다.

Sub Branch 

보조 브랜치는 기능을 구현하고, 배포를 준비하고, 이미 배포한 제품이나 서비스의 버그를 빠르게 해결해야 한다.

이 모든 것을 동시에 진행해야 하기 때문에 다양한 유형의 브랜치가 필요하다. 

우리가 사용할 브랜치의 종류는 다음과 같다:

• Feature Branch 
• Release Branch
• Hotfix Branch

각 브랜치마다 만든 목적이 있어야 하며, 어떤 브랜치에서 생성이 되었는지 어떤 브랜치에 Merge할 지에 따라 꼭 지켜야할 규칙이 있어야 한다.

다음의 분류는 개발에 대한 특성 그리고 목적 그리고 시간에 따라 분리하였다.

Feature Branch

Feature 브랜치 조만간에 배포할 기능(다음 혹은 언젠가...)을 개발하는 브랜치로 명칭한다.

우리는 여기서 기능을 개발하기 시작할 때부터 언제 배포할 수 있는지 알 수 없다.

그러므로 따로 분리된 브랜치에서 개발을 진행 후, 그 기능을 다 완성할 때까지 유지하며, 다 완성되면 Develop 브랜치로 Merge 한다.

Feature origin에 Push하지 않고 Local 에서 생성하는 브랜치다.

# git checkout -b feature develop
# git checkout develop
# git pull develop
.
.
# git merge --no-ff feature
# git push origin develop

Release Branch

Release 브랜치는 배포를 준비하는 브랜치이다.

릴리즈기간이 오래 될 수 있다 판단이 되면 즉시 폐기가 발생이 되어야 하며 폐기 전에는 Develop 브랜치에 반드시 병합이 되어야 한다.

Release 브랜치는 Develop 에서 작업하던 코드를 배포 하기전에, 필요한 버전 생성, 빌드 일정 등의 메타데이터를 준비하는 브랜치 이다.

Release 브랜치는 만드는 시점은 Develop 브랜치가 배포 할 수 있는 상태가 되었다고 판단 되었을 때이며, 배포 하고자 하는 기능이 Develop 브랜치에 병합 되어야 하고,

배포되지 않는 기능이 있는 경우 Release 브랜치를 만들때까지 기다렸다가 포함되어야 한다. 

Release 브랜치는 프로젝트의 버전 정책에 맞게 Release-Version (Number)로 생성한다.

Release 브랜치에서 진행 함으로서 Develop 브랜치는 다음에 배포할 때의 추가할 기능에 집중할 수 있다.

Develop 브랜치가 배포할 수 있는 상태가 되었을때 Release 브랜치를 생성하는 것이 중요하다.

이때, 배포해야 하는 기능이 모두 Develop 브랜치에 Merge 되어 있어야 하며, 이번에 배포하지 않을 기능은 다음 Release 브랜치를 만들 때까지 기다려야 한다.

Release 브랜치를 만든다는 것은 이제 배포 버전을 부여하겠다는 것을 의미한다. 

그 전까지 Develop 브랜치가 다음 배포가 어떤 모습일지 보여주지만, 아직 깨끗하게 정리된 상태가 아니다.

최종적으로 Release 브랜치를 만들어 '0.1', '0.3' 같은 버전이 붙을 때까지는 "진짜" 배포라고 할 수 없다.

Release 브랜치를 만들기로 하는 것이 버전 넘버를 새로 부여하기로 하는 것을 의미하므로 반드시 규칙에 따라야 한다.

새로 생성된 Release 브랜치는 잘 딜드하여 진짜 배포하기 전까지 유지되어야 한다. 

그동안 발견된 버그는 Develop 브랜치가 아닌 Release 브랜치에서 해결되어야 하고 새 기능은 Release 에 추가 하지 않는다.

새 기능이 추가되며 그 기능은 Develop 브랜치에 Merge하고 다음 배포를 대기, 기다려야 한다.

Release 브랜치가 진짜 배포할 상태가 되면 배포를 진행 한다.

Master 브랜치에 있는 것을 배포하는 것으로 정의했으므로 먼저 Release 브랜치를 Master로 Merge한다.

그리고 나중에 이 버전을 찾기 쉽도록 태그를 생성하여 지금 Master가 가리키는 Header 로 Commit 를 바라보게 한다

이제 Release 브랜치를 Develop 브랜치에 Merge하고 다음에 배포할 때 Release 브랜치에서 해결한 버그가 적용되도록 한다.

먼저 처음 두 단계, Master에 Merge하고 Tag를 생성한다.

# git checkout master
# git merge --no-ff release-1.2
# git tag -a 1.2 //마스터 브랜치에 태그 생성

이제 Master 로 병합 했기때문에 Develop 으로도 병합한다.

Release 브랜치에서 수정한 것이 앞으로도 계속 유지되어야 할것이다.

# git checkout develop
# git merge --no-ff release-1.2

마지막으로 Master / Develop 으로 병합 후 배포 했기때문에 더 이상 Release 브랜치는 필요없으므로 삭제한다.

# git branch -d release-1.2

Hotfix Branch

Hotfix 브랜치도 새로운 배포를 준비하는 것이기 때문에 Release 브랜치와 비슷하다.

하지만 hotfix 브랜치는 반드시 긴급용으로만 사용될 수 있도록 규칙이 있어야 한다. 

이것은 이미 배포 이후 시점 발생되는 장애 및 버그에 대한 문제를 해결 하기 위한다.

운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에 문제가 생기면 Master 브랜치에 만들어 둔 Tag로부터 Hotfix 브랜치를 생성한다.

그리고 버그를 잡는 개발자는 개발하는 동안, 다른 개발자들은  Develop 브랜치에서 계속 개발을 진해하면 된다. 

Hotfix 브랜치는 Master 브랜치에서 만든다. Develop 브랜치는 아직 불안정하기 때문이다. Hotfix 브랜치를 만들고 버그를 수정한다. 

# git checkout -b hotfix-1.2.1 master

브랜치를 만들고 버전 넘버를 바꾸는것은 규칙이다.

버그를 수정한 이후 다시 Master에 Merge하고 다시 Develop 브랜치에도 Merge 가 필수이다.

다음에 배포할 때도 수정된 버그사항이 포함되어 반영 된다. 

# git checkout master
# git merge --no-ff hotfix-1.2.1
# git tag -a 1.2.1

수정된 Hotfix 브랜치는 다시 Develop에 병합한다.

# git checkoup develop
# git merge --no-ff hotfix-1.2.1

만약 아직 Release 브랜치가 삭제되지 않고 있다면 Develop 뿐만 아닌 Release 브랜치에도 Merge 한다.

또한 Release 브랜치가 완료되면 결국 Develop 브랜치에 Merge 될 것이니 이점은 때에 따라서 판단 하여 진행 한다.

Develop 브랜치도 즉시 해결해야 하면 Release 브랜치가 끝날 때까지 기다리지 말고 Develop 브랜치에 즉시 Merge 한다.

마지막으로 Hotfix 브랜치를 삭제한다. (Hotfix 브랜치는 오래 유지될 필요가 없다)

# git branch -d hotfix-1.2.1

실천 시나리오

다음의 실천 시나리오를 통하여 이해관계를 높인다. 

1. 개발자 1 : Develop 에서 pull → feature 생성 후 A 기능 개발 진행 : OK
   개발자 2 : Develop 에서 pull → feature 생성 후 B 기능 개발 진행 : NO
   
   
2. 개발자 1 : Feature 에서 A 기능 완료 후 Develop 으로 병합.
   개발자 1 : Develop 에서 A 기능 배포 준비를 위한 Releaser-1.1 생성 후 병합. 
   개발자 1 : Release-1.1 에서 A 기능 버그 수정. (개발자 2, 3, 4.. 버그 수정 가능)
   개발자 2 : 아직 Feature 에서 B 기능 개발이 미완료됨. 
   개발자 1 : Release-1.1 에서 A 기능건 최종 수정완료. Master/Develop 으로 병합.
   개발자 1 : Release-1.1 삭제.
   개발자 2 : Feature 에서 B 기능이 완료되어 Develop으로 병합.
   개발자 2 : Develop에서 바로 배포를 위한 Release-1.2 생성 후 병합.
   개발자 2 : Release-1.2 에서 B 기능건 최종 수정완료. Master/Develop 으로 병합.
   개발자 2 : Releaser-1.2 삭제.

또한 우리는 다음과 같은 규칙을 가질 수 있다.

1. 개발자는 새로운 기능 개발건에 대하여 Feature 브랜치를 반드시 Develop 브랜치에서 분기 생성 한다. 
2. 개발자는 새로운 기능 개발건에 대하여 사전에 반드시 Develop으로부터 pull을 한다.
3. 신규 Feature Branch 명은 다음과 같이 작성한다. (브랜치명 규약은 현재 미정이며 이후 정책을 명시할 예정)
   feature branch  : feature/newBranch-1
   feature branch  : feature/project-newBranch
   feature branch  : feature/pms-newBranch
4. Feature 개발이 완료되면 Develop branch 로 병합한다. (Merge develop)
   이때 Feature 브랜치는 로컬에서 개발이 진행되도 되며, 원격으로 업로드가 가능하다.
5. Develop 에서 검수 및 테스트가 진행이 되어야 하며, Develop 은 항상 Master와 형상이 유지 되어야 한다.
6. 배포 및 출시준비를 위한 Release-1.1 으로 Branch 생성한다. (버전 규약 필수)
7. Release 단계에서 버그 및 수정사항이 발생하면, Releaser-1.1에서 수정 후 커밋이 발생되어야 한다. 
8. 최종 배포를 위하여 Master 병합 후 배포가 된다.