Git flow

분산되었지만 중앙 집중식

• git flow를 잘 활용하지 않으면 사실상 중앙 집중식과 같은 방식으로 협업을 하는 것과 같다.

전체적인 흐름

 

The main branches

저장소에는 두 개의 영원한 메인 branch가 존재

• master : 제품으로 출시될 수 있는 branch
• develop : 다음 출시 버전을 개발하는 branch

 

Supporting branches

지원 분기를 사용하여 팀 구성원 간의 병렬 개발을 지원하고, 기능을 쉽게 추적하고, 릴리즈를 준비하고, 수정할 수 있다.

메인 branch와 달리 결국 제거될 것이기 때문에 제한된 수명을 갖고 있다.

• Feature branches
• Release branches
• Hotfix branches

각 분기는 특정 목적이 있으며 엄격한 규칙을 따른다.

 

Feature branches

• develop에서 분기해야 한다.
• develop으로 병합해야 한다.
• master, develop, release-*, hotfix-* 이외 naming

 

feature branches는 향후 release할 기능을 개발하기 위해 사용한다.

이후 develop에 merge되어 제거되거나, 기능개발에 실패할 경우 곧바로 제거된다.

 

Feature branch 만들기

새로운 작업을 시작할 때 develop branch에서 branch를 만든다.

$ git checkout develop
'develop' 브랜치로 전환

$ git merge --no-ff myfeature
병합

$ git branch -d myfeature
myfeature branch 삭제

$ git push origin develop

--no-ff를 이용해 항상 새로운 commit을 생성한다.

feature branch에 대한 history 정보가 손실되는 것을 방지하고 기능을 함께 추가한 모든 커밋을 함께 그룹화 할 수 있다.

 

Release branch

• develop에서 분기해야한다.
• develop이나 master로 merge해야 한다.
• release-*로 naming

Release branch 생성

develop branch로 부터 생성된다. 현재 버전이 1.15 이고 다음 release할 버전이 1.2라고 가정한다.

이때 대규모 새 기능을 추가하는 것은 금지된다.

$ git checkout -b release-1.2 develop
새로운 브랜치 "release-1.2"로 전환

$ ./bump-version.sh 1.2
파일이 성공적으로 수정되었으며, version은 1.2

$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1files changed, 1 insertion(+), 1 deletions(-)

Release branch 완료

release branch가 실제 release 될 준비가 되면 몇 가지 작업을 수행해야 한다.

1. master 로 병합
2. 나중에 쉽게 참조할 수 있도록 commit에 태그를 지정
3. develop에 다시 병합
4.  

$ git checkout master
'master' branch로 전환

$ git merge --no-ff release-1.2

$ git tag -a 1.2

$ git checkout develop

$ git merge --no-ff release-1.2

$ git branch -d release-1.2
release-1.2 branch 삭제

 

Hotfix branches

• master에서 분기해야 한다.
• develop, master으로 병합해야 한다.
• hotfix-* 로 naming

계획되지 않은 release분기라고 생각할 수 있다.

즉시 조치를 취해야 하며 다른 사람이 빠른 수정을 준비하는 동안 팀은 develop branch에서 계속 작업할 수 있는 것이 핵심이다.

 

Hotfix branch 생성

master branch로부터 생성된다. 예를 들어 1.2 버전에서 심각한 버그가 발행했다고 가정하자.

이때 현재 develop은 아직 불안정하므로 master branch에서 hotfix branch를 생성해 문제를 해결한다.

$ git checkout -b hotfix-1.2.1 master
새로운 "hotfix-1.2.1" branch 로 이동

$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.

$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

분기 후 버전 번호를 꼭 올려야 한다.

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

Hotfix branch 종료

버그 수정이 끝나면, master branch로 merge되어야 한다.

또 다음 release에도 버그 수정을 유지 시키기 위해 develop 으로 merge되어야 한다.

release branch가 종료 되었을 때와 비슷하다.

 

$ git checkout master
'master' branch로 이동

$ git merge --no-ff hotfix-1.2.1

$ git tag -a 1.2.1

$ git checkout develop
'develop' branch로 이동

$ git merge --no-ff hotfix-1.2.1

$ git branch -d hotfix-1.2.1

여기서 예외사항은 release branch가 현재 존재하면 hotfix 변경사항을 develop 대신에 release에 merge한다.

다시한번 큰 흐름으로 보면 다음과 같다.