A. git-flow는 Vincent Driessen이 제안한 깃git 브랜치 활용 모델로 많은 기업들에서 활용하고 있다.
Vincent Driessen의 블로그 글 A successful Git branching model에 자세한 설명이 나온다.
주 브랜치(the main branches)
gitflow의 주 브랜치는 master와 develop 브랜치다. 원문을 살펴보자.
The central repo holds two main branches with an infinite lifetime:
master
develop
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.
중앙 저장소는 무한한 수명을 갖고 있는 두 주 브랜치(분기)를 갖고 있습니다.
master
develop
master 브랜치는 모든 Git 사용자에게 친숙할 것입니다. master 브랜치와 평행하게 develop라고 불리는 또 다른 브랜치가 존재합니다.
우리는 origin/master를 HEAD의 소스 코드가 항상 프로덕션 준비 상태를 반영하는 메인 브랜치로 생각합니다.
origin/develop는 HEAD의 소스 코드가 항상 다음 릴리스를 위한 최신 개발 변경 사항이 반영된 상태를 반영하는 메인 브랜치로 생각합니다. 누군가는 origin/develop를 통합 브랜치라고 부르기도 합니다.
정리하면 master, develop 브랜치 용도는 아래와 같다.
master: 프로덕션 준비 상태 브랜치
develop: 다음 릴리스를 위한 최신 개발 변경 사항이 반영된 상태 브랜치
지원 브랜치(supporting branches)
지원 브랜치는 feature, release, hotfix 3가지 브랜치를 말한다. 원문을 읽어보자.
Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
The different types of branches we may use are:
Feature branches
Release branches
Hotfix branches
master 브랜치와 develop 브랜치 옆에 다양한 지원 브랜치는 팀원 간 병렬 개발을 돕고, 기능을 쉽게 추적하고, 프로덕션 배포를 준비하고, 현재 서비스 중인(live) 프로덕션의 문제들을 빠르게 해결하는데 도움이 됩니다. 주 브랜치들과 다르게 이들 브랜치들은 언젠가 제거되기 때문에 항상 제한된 수명을 갖고 있습니다.
사용할 수 있는 브랜치 유형은 다음과 같습니다.
feature 브랜치
release 브랜치
hotfix 브랜치
Feature 브랜치
원문을 보자.
Feature branches
May branch off from:
develop
Must merge back into:
develop
Branch naming convention:
anything except master, develop, release-*, or hotfix-*
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
Feature branches typically exist in developer repos only, not in origin.
feature 브랜치
develop에서 분기될 수 있습니다
develop으로 다시 병합해야 합니다.
브랜치 명명 규칙: master, develop, release-*, hotfix-* 제외한 모든 것
feature(기능) 브랜치들(또는 때때로 토픽 브랜치라고도 함)은 곧 출시되거나 먼 미래의 릴리스를 위한 새로운 기능을 개발하는데 사용됩니다. 기능 개발을 시작할 때 이 기능이 포함될 대상 릴리스는 이 시점에 알 수 없습니다. feature 브랜치의 본질은 해당 기능이 개발 중인 한 존재하지만, 결국에 develop 브랜치로 병합되거나(새 기능을 다음 릴리스에 확실히 추가하기 위해서) 또는 폐기됩니다(실험 결과가 실망스러운 경우). feature 브랜치는 보통 개발자 저장소에만 존재하고 origin에는 존재하지 않습니다.
feature 브랜치는 새로운 기능 개발을 위한 브랜치다.
Release 브랜치
원문을 보자.
Release branches
May branch off from:
develop
Must merge back into:
develop and master
Branch naming convention:
release-*
Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.
release 브랜치
develop 브랜치에서 분기될 수 있습니다.
develop 브랜치와 master 브랜치로 다시 병합해야 합니다.
브랜치 명명 규칙: release-*
release 브랜치는 새로운 프로덕션 릴리스 준비를 지원합니다. 릴리스 브랜치가 마지막 순간에 i 점을 찍고 t를 교차하는 것을 허용해줍니다. 게다가 사소한 버그 수정과 릴리스에 대한 메타데이터(버전 번호, 빌드 날짜 등)를 준비할 수 있게 해줍니다. 이런 모든 작업을 release 브랜치에서 수행하면 develop 브랜치는 다음 대규모 릴리스를 위한 기능들을 받을 수 있게 됩니다.
release 브랜치는 새로운 프로덕션 릴리스 준비 브랜치다.
Hotfix 브랜치
원문을 보자.
Hotfix branches
May branch off from:
master
Must merge back into:
develop and master
Branch naming convention:
hotfix-*
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.
hotfix 브랜치
master 브랜치에서 분기할 수 있습니다.
develop 브랜치와 master 브랜치로 다시 병합해야 합니다.
브랜치 명명 규칙: hotfix-*
hotfix 브랜치는 계획에 없었지만, 새로운 프로덕션 릴리스를 준비하기 위한 브랜치라는 점에서 release 브랜치와 매우 비슷합니다. hotfix 브랜치는 서비스 중인 프로덕션 버전의 원하지 않는 상태를 즉시 조치를 취해야할 필요성에서 비롯됩니다. 프로덕션 버전의 치명적인 버그를 즉시 해결해야 할 때, hotfix 브랜치는 프로덕션 버전을 표시하는 master 브랜치의 해당 태그에서 분기될 수 있습니다.
핵심은 다른 사람이 빠른 프로덕션 수정을 준비하는 동안, 다른 팀원들의 (develop 브랜치에서) 작업이 지속된다는 것입니다.
hotfix 브랜치는 서비스 중인 프로덕션 버그를 수정하기 위한 브랜치다.
git-flow 브랜치 도표
앞에서 살펴본 각 브랜치를 표로 정리하면 아래와 같다.
| master | develop | feature | release | hotfix | |
| 주 브랜치 | O | O | X | X | X |
| 지원 브랜치 | X | X | O | O | O |
| 수명 | 평생 | 평생 | 일시적 | 일시적 | 일시적 |
| ~로부터 분기 | - | - | develop | develop | master |
| ~로 병합 | - | - | develop | develop, master | develop, master |
| 명명 규칙 | master | develop | master, develop, release-*, hotfix-* 제외한 모든 것 |
release-* | hotfix-* |
| 용도 | 프로덕션 준비 상태 | 다음 릴리스에 대한 최신 개발 변경 사항이 반영된 상태 | 새로운 기능 개발 | 새로운 프로덕션 릴리스 준비 | 서비스 중인 프로덕션 버그를 수정 |
git-flow 예
아래 그림은 Vincent Driessenr의 A successful Git branching model 글에 나오는 gitflow 예이다.
활용 사례
실제 활용하는 방식은 약간씩 회사마다 다르다. 특히 브랜치명 명명 규칙은 Vincent Driessenr의 제안대로 하지 않고 회사마다 약간씩 다르게 하는 경우가 많다. 아래 예는 Vincent Driessenr의 그림과 거의 비슷하고, 위에서 아래가 아닌 왼쪽에서 오른쪽으로 그렸다고 보면 된다.
git을 시작하면 과거에는 master였지만 지금은 기본 브랜치가 main이다. master로 바꾸지 않고 기본 main 그대로 활용한 예이다. 위 그림을 시간 흐름대로 설명해 보면 다음과 같다.
1. main 브랜치에서 첫 커밋을 하고 v0.1.0이란 태그를 추가한다.
2. main 브랜치에서 분기해서 develop 브랜치를 만든다.
3. develop 브랜치에서 다시 분기해서 feature/B 브랜치를 만들고, feature/A 브랜치도 만든다.
4. main 브랜치 v0.1.0에서 버그가 발견되어서 hotfix-v0.1.1 브랜치를 분기해서 작업한 뒤 main과 develop에 병합한다. hotfix-v0.1.1 브랜치는 필요 없어져서 삭제한다. main 브랜치 커밋에 v0.1.1이란 태그를 추가한다.
5. develop의 hotfix 커밋을 feature-A와 feature-B 브랜치로 반영한다.
6. feature-A 브랜치에서 작업한 뒤 커밋하고, develop으로 병합한다. feature-A 브랜치는 필요 없어져서 삭제한다.
7. develop 브랜치에서 release-v0.2.0 브랜치를 만들고, QA를 요청한다.
8. QA를 기다리면서 feature B 작업 커밋 한다.
9. QA 요청 중 버그와 오류가 발견되어 수정 커밋한다.
10. QA가 종료되어 release-v0.2.0 브랜치를 main과 develop으로 병합한다. release-v0.2.0 브랜치는 삭제한다.
11. main 브랜치에 v0.2.0이란 태그를 추가한다.
12. feature/B 브랜치에서 작업했다. feature-B 브랜치를 develop으로 병합한다. feature-B 브랜치를 삭제한다.
13. develop에서 간단한 수정 사항이라 feature 브랜치를 만들지 않고 커밋한다.
위 예에서는 release 브랜치를 QA용 브랜치로, main 브랜치를 서비스 배포용 브랜치로 사용한다. 보통 QA용 서버를 staging이라고 하고, 서비스용 서버를 production(줄여서 prod라고 많이 한다)이라고 한다. 각 서버와 브랜치 관계를 정리하면 아래와 같다.
| 브랜치 | 서버 이름 | |
| 개발 | develop | develop(줄여서 dev) |
| QA | release | staging |
| 서비스 | main(또는 master) | production(줄여서 prod) |
대부분 develop개발 서버의 경우 개발자 로컬 서버를 이용하는 경우가 많다.
git-flow 활용 시 주의 사항
| master | develop | feature | release | hotfix | |
| ~로부터 분기 | - | - | develop | develop | master |
| ~로 병합 | - | - | develop | develop과 master | develop과 master |
| 명명 규칙 | master | develop | master, develop, release-*, hotfix-* 제외한 모든 것 | release-* | hotfix-* |
지원 브랜치의 분기와 병합 규칙, 명명 규칙을 반드시 지켜야 한다. 이 규칙을 어기는 것이 가장 흔히 범하는 실수다. 왜 규칙을 지켜야 할까? 병합할 때 브랜치 이름을 보고 판단한다. 규칙대로 작업했을 거라고 가정하고 병합하게 되는데, 규칙을 지키지 않았다면 코드가 꼬여서 병합 때 충돌conflict이 발생한다.
실수 예1
release 브랜치에서 hotfix 브랜치를 분기. hotfix 브랜치는 master(또는 main)에서만 분기할 있다. QA 중인 release 브랜치에서 버그나 오류가 많아도 hotfix나 feature란 이름으로 브랜치를 절대 만들면 안 된다. 코드 리뷰 때문에 feature 브랜치를 만들어야 할 거 같지만 release에서 develop으로 병합하는 풀리퀘스트Pull Request에서 리뷰가 가능하다. 그냥 release 브랜치에서 커밋하면 된다.
실수 예2
feature에서 feature 브랜치를 분기. feature 브랜치는 develop에서 분기해야 한다.
참고할만한 글
배달의 민족: 우린 Git-flow를 사용하고 있어요
Introducing GitFlow by datasift