문제점.
- 장기간, 단기간 브랜치 관리가 되어야 하며, 분리 또는 유지가 되어야 한다.
- 개발이 동시에 진행이 될수 있어야 한다.
모델은 단순히 소프트웨어 개발 프로세스를 관리하려고 팀원 모두가 따라야 하는 치짐일 뿐이다.
개발자 모두 origin에 push/pull할 수 있지만,
중앙집중식에서는 모든 개발자가 다른 개발자가 수정한 것까지도 pull 해야 한다.
팀에서 수정한 것까지도 pull 해야 한다.
예를 들어 혼자 하기 어려운 기능은 둘, 셋이서 함께 개발하고 나서 origin에 push해야 한다.
개발 중인 것을 origin에 push하지 않는다.
주 메인 브랜치
개발자는 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 서버에 베포할 수도 있다.
보조 브랜치
master와 develop 브랜치말고 다른 브랜치도 필요하다.
기능을 구현하고, 배포를 준비하고, 이미 배포한 제품이나 서비스의 버그를 빠르게 해결해야 한다.
이 모든 것을 동시에 진행해야 하기 때문에 다양한 브랜치가 필요하다.
우리가 사용할 브랜치의 종류는 다음과 같다:
- feature 브랜치
- release 브랜치
- hotfix 브랜치
각 브랜치마다 만든 목적이 있어야 하며,
어떤 브랜치에서 생성이 되었는지 어떤 브랜치에 merge할 지에 따라 꼭 지켜야할 규칙이 있어야 한다.
다음의 분류는 개발에 대한 특성 그리고 목적 그리고 시간에 따라 분리하였다.
Feature Branch
feature 브랜치 조만간에 배포할 기능(다음 혹은 언젠가)을 개발하는 브랜치로 명칭한다.
우리는 여기서 기능을 개발하기 시작할 때부터 언제 배포할 수 있는지 알 수 없다.
그러므로 따로 분리된 브랜치에서 개발을 진행 후,
그 기능을 다 완성할 때까지 유지하며,
다 완성되면 develop 브랜치로 merge한다.
feature origin에 push하지 않고 local 에서 생성하는 브랜치다.
feature 브랜치는 보통 개발자 저장소에만 있는 브랜치고 origin에는 push하지 않는다.
- 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 브랜치가 배포 할 수 있는 상태가 되었다고 판단 되었을 때이며,
배포 하고자 하는 기능이 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