Page History

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

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

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

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

왜 사용하게 되었는가?

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

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

순차적으로 개발 되지 않는 이유는 아무리 제대로된 기획이나 요구사항 명세서가 있더라도 프로젝트를 진행하는 과정에서 소소한 변경들이 일어나기 마련이고,때로는

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

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

대부분 또한 대부분은 A 라는 기능을 개발하다가 개발하고 있는 중 B, C, D 기능을 병행개발 해야하는 경우가 발생한다.기존에는 하나의 소스에서 작업을 하다보면 주석처리하거나 극단적으로는 디렉토리를 별도로 구성해서 개발되는 ...  등 다른 기능을 병행 해야 할 경우가 많이 발생 한다된다. 

Image RemovedImage Added

브랜치 종류

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

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

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

Main Branch 

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

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

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

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

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

즉, 정의한 대로 master로 merge하는 것은 새 버전을 배포하는 것을 의미한다.우리는 master 브랜치에 커밋될 때마다 Git hook 스크립트로 자동으로 빌드하고 말아서 운영 서버로 배포 목적을 준비할 것이다

보조 브랜치

Sub Branch 

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

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

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

• feature 브랜치
• release 브랜치
• hotfix 브랜치Feature Branch 
• Release Branch
• Hotfix Branch

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

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

Feature

Branch

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

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

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

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

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

Release

Branch

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

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

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

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

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

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

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

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

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

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

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

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

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

새로 만든 release 브랜치는 잘 말아서 진짜로 배포할 때까지 유지한다.

그동안 발견한 버그는 develop 브랜치가 아니라 이 브랜치에서 해결하고 새 기능은 이 브랜치에 추가하지 않는다.

그런 기능은 develop 브랜치에 merge하고 다음 배포로 미뤄야 한다.

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

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

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

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

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

그리고 나중에 이 버전을 찾기 쉽도록 태그를 만들어 생성하여 지금 master가 가리키는

커밋을 가리키게 한다.

그리고 release 브랜치를 develop 브랜치에 merge하고

다음에 배포할 때 release Master가 가리키는 Header 로 Commit 를 바라보게 한다

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

먼저 처음 두 단계, master에 merge하고 tag를 단다:

git checkout master

git merge Master에 Merge하고 Tag를 생성한다.

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

# git tag -a 1.2

 //마스터 브랜치에 태그 생성

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

release 브랜ㅊ니에서 Release 브랜치에서 수정한 것이 앞으로도 계쏙 유지 되어야 한다.

git checkout develop

git merge 계속 유지되어야 할것이다.

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

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

# git branch -d release-1.2

Hotfix Branch

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

하지만 hotfix 브랜치는 긴급용으로만 사용한다.이것은 이미 배포한 운영 버전에 생긴 문제를 해결하기 위해 만든다반드시 긴급용으로만 사용될 수 있도록 규칙이 있어야 한다. 

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

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

그리고 버그를 잡는 사람이 일하는 동안에도 다른 사람들은

develop 브랜치에서 하던 일을 계속 할 수 있다.

hotfix 브랜치는 master 브랜치에서 만든다.

develop 브랜치는 아직 불안정하기 때문에 hotfix 브랜치를 만들고 거기서 버그를 잡는다

git checkout -b 개발자는 개발하는 동안, 다른 개발자들은  Develop 브랜치에서 계속 개발을 진해하면 된다. 

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

# git checkout -b hotfix-1.2.1 master

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

./bump-version.sh 1.2.1

git commit -a -m "version 1.2.1"git commit -m "긴급반영"

버그를 잡았으면 다시 master에 merge하고 다시 develop 브랜치에도 merge해야 한다. 그래야 다음에 배포할 때도 포함된다. release 브랜치를 마치는 방법과 같다

git checkout master

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

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

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

# git tag -a 1.2.1

그리고 develop에서 수정된 Hotfix 브랜치는 다시 Develop에 병합한다.

# git checkoup develop

# git merge --no-ff hotfix-1.2.1

만약 아직 release Release 브랜치가 삭제되지 않고 있다면

develop 브랜치가 아니라 release 브랜치에 merge한다.

release Develop 뿐만 아닌 Release 브랜치에도 Merge 한다.

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

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

문제가 생기지 않도록 조심스럽게 merge한다.

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

# git branch -d hotfix-1.2.1

실천 시나리오

여기서 우리는 다음과 같이 전략을 가질 수 있다.다음의 실천 시나리오를 통하여 이해관계를 높인다. 

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

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

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