Git 브랜칭 전략 : Git-flow와 Github-flow

😎 Git 브랜치를 효과적으로 나누고, 관리하기

대표적인 브랜칭(branching) 전략

• Git-flow
• GitHub-flow

📃Git-flow

Git-flow는 브랜치를 크게 4가지로 나누어 개발하는 전략입니다.

• 메인 브랜치(Main branch)
• 피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)
• 릴리스 브랜치(Release branch)
• 핫픽스 브랜치(Hotfix branch)

 

가장 중심이 되는 브랜치는 master와 develop 브랜치이며,  

merge된 feature, release, hotfix 브랜치는 삭제하도록합니다.

 

Git-flow 전략은 주기적으로 배포를 해야하는 프로젝트에는 적합하지만,

브랜치가 많아 복잡하고 어떤 프로젝트에 따라서는 몇몇 브랜치가 애매한 포지션을 가질 수 있습니다.

 

✏️ 참고 Vincent Driessen의 branching model(번역본) 그리고 이를 구현한 Git 확장 모듈 https://github.com/nvie/gitflow 모듈 설치방법  http://huns.me/development/1131) https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

 

 

메인 브랜치(Main branch)

master 브랜치와 develop 브랜치, 이 두 종류의 브랜치를 보통 메인 브랜치로 사용합니다.

master 브랜치와  develop 브랜치를 병행으로 유지합니다.

 

master

• 배포 가능한 상태만을 관리하는 브랜치

 

develop

• 다음에 배포할 것을 개발하는 브랜치
• develop  브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행

보조 브랜치(Supporting branch)

피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)

 

갈라져 나온 브랜치 :  develop 다시 merge할 브랜치 : develop 브랜치 이름 규칙 : master, develop, release-*, hotfix-*를 제외한 것

 

• 기능을 개발하는 브랜치로,  develop 브랜치로부터 분기
• feature 브랜치는 그 기능을 다 완성할 때까지 유지하고, 다 완성되면  develop 브랜치로 merge (다음 배포에 확실히 넣을거라고 판단될 때 merge하고, 결과가 실망스러우면 아예 버린다)
• feature 브랜치는 보통 개발자 저장소에만 있는 브랜치고 origin에는 push 하지 않는다

💡 develop 브랜치와 feature 브랜치 기존에 잘 작동하는 개발 코드(develop 브랜치)와 새로 변경될 개발코드(feature 브랜치)를 분리하고 각각 보존하는 것 feature 브랜치는 Git-flow 전략에서 지칭하는 단위 개발 브랜치의 의미를 갖는다

 

릴리즈 브랜치(release branch)

 

갈라져 나온 브랜치 :  develop 다시 merge할 브랜치 : develop, master 브랜치 이름 규칙 : release-*

 

• develop 브랜치에 이번 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성
• 배포를 위한 최종적인 버그 수정 등의 개발을 수행
• 배포 가능한 상태가 되면  master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그를 추가
• release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은  develop 브랜치에도 적용해 주어야함! 그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행

 

핫픽스 브랜치(hotfix branch)

 

갈라져 나온 브랜치 :  master 다시 merge할 브랜치 : develop, master 브랜치 이름 규칙 : hotfix-*

 

• 배포한 버전에서 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치
• 버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다
• 이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해 주어야함

📃Github-flow

 

Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜칭 전략입니다, 흐름이 단순한 만큼 role도 단순합니다. master 브랜치에 대한 role만 정확하다면 나머지 브랜치들에 대해서는 관여하지 않습니다. 즉, hotfix 브랜치나 feature 브랜치를 구분하지 않습니다. 다만 우선순위가 다를 뿐입니다. pull request 기능을 사용하도록 권장합니다.

 

이 브랜칭 전략은 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용합니다.

 

✏️참고 Scott chacon의 GitHub Flow(번역본) https://guides.github.com/introduction/flow/ http://blog.programster.org/git-workflows https://www.tricksofthetrades.net/2016/04/26/github-flow/

 

사용법

1. master 브랜치는 어떤 때든 배포가 가능하다

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
• 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
• merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다

2. master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성하자

• 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
• 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
• 커밋메시지를 명확하게 작성하자

 

3. 원격지 브랜치로 수시로 push 하자

• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

 

4. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자

5. 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다

• 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
• 물론 CI도 통과해야한다!

6. master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다

 

🤔 어떤 브랜칭 전략을 사용해야할까?

 

배달의 민족을 개발하는 우아한 형제들이 GitHub-flow를 사용하다 Git-flow로 브랜치 전략을 바꿨다는 글을 접했습니다. 이렇듯 브랜칭과 배포에 대한 전략을 상황에 따라 바뀔 수 있습니다.

 

조직의 규모, 서비스의 특징, 프로젝트에 참여하고 있는 구성원들이 제각기 다르기 때문입니다.

 

따라서 개발팀은 협의를 통해 브랜칭과 배포에 대한 전략을 결정하고 운영해야하며, 이 전략은 공유되어 구성원들이 학습-체득화할 수 있는 것이 중요하다는 결론을 내릴 수 있습니다.

 

✏️ 참고 배달의 민족, 우아한 형제들 ‘우린 Git Flow를 사용하고 있어요‘ http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html ‘상시배포에는 Git-flow가 적합하지 않다?’에 대한 토론 https://www.slipp.net/questions/244 git-flow, github-flow, gitlab-flow https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/