가장 기본적인 브랜치 모델 (스탠다드) 을 기준으로 작성한다.
(다음의 사용되는 모델은 http://nvie.com/posts/a-successful-git-branching-model/ 제공되는 기본적 모델을 내용으로 인용 하였음. 아니 거의 똑같음)
기본적 모델은 단순히 소프트웨어 개발 프로세스를 구성하고 개발 구성원 모두가 동일한 지침 과 규정에 따르기 위하여 만들었다.
개발 구성원 모두는 Remote 에 push/pull 할 수 있지만, 기본적으로 pull 을 먼저 진행하는것을 원칙으로 한다.
왜 사용하게 되었는가?
각각의 기능이 순차적으로 개발되거나 하나의 기능이 완료된 사항에서, 다른 기능이 개발/유지보수 되지 않는다.
차기 버전을 개발하는 도중에 운영중인 버전에 대한 긴급한 패치 등이 이루어지는 경우가 많다.
순차적으로 개발 되지 않는 이유는 아무리 제대로된 기획이나 요구사항 명세서가 있더라도 프로젝트를 진행하는 과정에서 소소한 변경들이 일어나기 마련이고,
때로는 정책적인 이슈로 인해서 특정 기능의 개발이 지연 되는 경우가 대부분이다.
대부분 A 라는 기능을 개발하다가 B, C, D 기능을 병행개발 해야하는 경우가 발생한다.
기존에는 하나의 소스에서 작업을 하다보면 주석처리하거나 극단적으로는 디렉토리를 별도로 구성해서 개발되는 경우가 많이 발생 한다.
브랜치 종류
5가지 브랜치가 존재 한다.
항상 유지되는 주 메인 브랜치(master, develop)이 있으며, 일정 기간동안만 유지 되는 보조 브랜치(feature, release, hotfix)가 있다.
- master : 언제나 배포가 가능할수 있는 branch
- develop : 기능 개발 및 배포 버전을 준비하고 개발자들 간 공유 pull/push 해야 하는 Branch
- release : 단기간 배포 버전을 출시해야 하는 Branch (버전관리 필수)
- feature : 장기간 기능을 개발하는 Branch
- hotfix : 배포된 이후 긴급 또는 버그를 수정하는 Branch
주 메인 브랜치
개발자는 master 브랜치와 develop 브랜치를 병행으로 유지한다.
먼저 배포했거나 곧 배포할(production-ready) 코드는 origin/master에 두고 관리한다.
그리고 다음에 배포할 것을 개발하는 코드는 origin/develop에 두고 관리한다.
이 브랜치를 "통합 브랜치(integration branch)"라고 부르기도 하는데, 이 브랜치를 자동으로 매일 빌드하는데 사용한다.
develop branch의 코드가 안정되고 배포할 준비가 되면 곧 master로 merge하고 배포 버전으로 태그를 단다.
즉, 정의한 대로 master로 merge하는 것은 새 버전을 배포하는 것을 의미한다.
우리는 master 브랜치에 커밋될 때마다 Git hook 스크립트로 자동으로 빌드하고 말아서 운영 서버로 배포 목적을 준비할 것이다.
이와 같은 규칙을 통해 jenkins와 같은 빌드 툴을 이용해 master branch에 commit이 될 때 TAG를 달고 binary를 생성하는 과정을 자동화하고, 이를 staging 서버에 베포할 수도 있다.
보조 브랜치
기능을 구현하고, 배포를 준비하고, 이미 배포한 제품이나 서비스의 버그를 빠르게 해결해야 한다.
이 모든 것을 동시에 진행해야 하기 때문에 다양한 브랜치가 필요하다.
우리가 사용할 브랜치의 종류는 다음과 같다:
- feature 브랜치
- release 브랜치
- hotfix 브랜치
각 브랜치마다 만든 목적이 있어야 하며, 어떤 브랜치에서 생성이 되었는지 어떤 브랜치에 merge할 지에 따라 꼭 지켜야할 규칙이 있어야 한다.
다음의 분류는 개발에 대한 특성 그리고 목적 그리고 시간에 따라 분리하였다.
Feature 브랜치
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 브랜치
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 브랜치가 아니라 이 브랜치에서 해결하고 새 기능은 이 브랜치에 추가하지 않는다.
그런 기능은 develop 브랜치에 merge하고 다음 배포로 미뤄야 한다.
release 브랜치가 진짜 배포할 상태가 되면 배포한다.
master 브랜치에 있는 것을 배포하는 것으로 정의했으므로
먼저 release 브랜치를 master로 merge한다.
그리고 나중에 이 버전을 찾기 쉽도록 태그를 만들어 지금 master가 가리키는
커밋을 가리키게 한다.
그리고 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으로 병합 후 배포 했기때문에 더 이상 필요없으므로 삭제한다.
git branch -d release-1.2
hotfix 브랜치
hotfix 브랜치도 새로운 배포를 준비하는 것이기 때문에 release 브랜치와 비슷하다.
하지만 hotfix 브랜치는 긴급용으로만 사용한다.
이것은 이미 배포한 운영 버전에 생긴 문제를 해결하기 위해 만든다.
운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에 문제가 생기면
master 브랜치에 만들어 둔 tag로부터 hotfix 브랜치를 만든다.
그리고 버그를 잡는 사람이 일하는 동안에도 다른 사람들은
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 --no-ff hotfix-1.2.1
git tag -a 1.2.1
그리고 develop에서 병합한다.
git checkoup develop
git merge --no-ff hotfix-1.2.1
만약 아직 release 브랜치가 삭제되지 않고 있다면
develop 브랜치가 아니라 release 브랜치에 merge한다.
release 브랜치가 완료되면 결국 develop 브랜치에 merge될 것이다.
그런데 develop 브랜치도 즉시 해결해야 하면 release 브랜치가 끝날 때까지
기다리지 말고 develop 브랜치에 즉시 merge한다.
문제가 생기지 않도록 조심스럽게 merge한다.
이제 브랜치를 삭제한다.
git branch -d hotfix-1.2.1
실천 시나리오
여기서 우리는 다음과 같이 전략을 가질 수 있다.
- 개발자 1 : develop 에서 pull 후 feature 생성 후 AA개발 진행 : OK
개발자 2 : develop 에서 pull 후 feature 생성 후 BB개발 진행 : NO - 개발자 1 : feature 에서 AA개발 완료 후 develop 으로 병합.
개발자 1 : develop 에서 AA개발건 배포 준비를 위한 releaser-1.1 생성 후 병합.
개발자 1 : release-1.1 에서 AA개발건 버그 수정. (개발자 2, 3, 4.. 버그 수정 가능)
개발자 2 : 아직 feature 에서 BB 개발이 미완료됨.
개발자 1 : release-1.1 에서 AA개발건 최종 수정완료. Master/develop 으로 병합.
개발자 1 : release-1.1 삭제.
개발자 2 : feature 에서 BB개발이 완료되어 develop으로 병합.
개발자 2 : develop에서 바로 배포를 위한 release-1.2 생성 후 병합.
개발자 2 : release-1.2 에서 BB개발건 최종 수정완료. Master/develop 으로 병합.
개발자 2 : releaser-1.2 삭제.
또한 우리는 다음과 같은 규칙을 가질 수 있다.
- 개발자는 새로운 기능 개발건에 대하여 feature 브랜치를 반드시 develop 브랜치에서 분기 생성 한다.
- 개발자는 새로운 기능 개발건에 대하여 사전에 반드시 develop으로부터 pull을 한다.
- 신규 feature branch 명은 다음과 같이 작성한다.
feature branch 명 : feature/newBranch-1
feature branch 명 : feature/project-newBranch
feature branch 명 : feature/pms-newBranch - feature 개발이 완료되면 develop branch 로 병합한다. (Merge develop)
이대 feature 브랜치는 로컬에서 개발이 진행되도 되며, 원격으로 업로드가 가능하다. - develop 에서 검수 및 테스트가 진행이 되어야 하며, develop 은 항상 master와 형상이 유지 되어야 한다.
- 배포 및 출시준비를 위한 release-1.1 으로 branch 생성한다. (버전 규약 필수)
- release 단계에서 버그 및 수정사항이 발생하면, releaser-1.1에서 수정 후 커밋이 발생되어야 한다.
- 최종 배포를 위하여 Master 병합 후 배포가 된다.