Git-flow
브랜치를 크게 4가지로 나누어 개발하는 전략
- 메인 브랜치(Main branch)
- 피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)
- 릴리스 브랜치(Release branch)
- 핫픽스 브랜치(Hotfix branch)
이 중 가장 중심이 되는 브랜치는 master와 develop 브랜치이며,
merge된 feature, release, hotfix 브랜치는 삭제하도록 합니다.
Git-flow 전략은 주기적으로 배포를 해야하는 프로젝트에는 적합하지만,
브랜치가 많아 복잡하고 어떤 프로젝트에 따라서는 몇몇 브랜치가 애매한 포지션을 가질 수 있습니다.
메인 브랜치(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 전략에서 지칭하는 단위 개발 브랜치의 의미를 갖는다
릴리즈 브랜치(Supporting 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
1. master 브랜치는 어떤 때든 배포가 가능하다
- master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
- 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
- merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins(Docker)로 테스트 한다
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가 일어나면 자동으로 배포가 되도록 설정해놓는다
