Git flow
git-flow 브랜치 모델은
다섯 개의 규칙과 잔뜩의 사무 처리로 이루어져 있어요. 규칙은 쉬워요. 사람들이
릴리스 당일 저녁 6시에 틀리는 쪽은 사무 처리예요 — 핫픽스를 main 에 머지하고
develop 을 잊는다든가, 엉뚱한 브랜치에 태그를 단다든가요.
⌘K → Git flow 가 그 사무 처리를 대신해요.

구성
| 브랜치 | 담는 것 |
|---|---|
릴리스된 브랜치 (main) |
운영에 올라가 있는 것. 모든 릴리스는 여기에 태그돼요. |
통합 브랜치 (develop) |
릴리스와 릴리스 사이에 끝난 작업이 쌓이는 곳. |
feature/* |
하나의 작업 단위. develop 에서 갈라져 나와요. |
release/* |
안정화 중인 버전. develop 에서 갈라져 나와요. |
hotfix/* |
급한 수정. main 에서 갈라져 나와요 — 운영은 develop 을 기다릴 수 없으니까요. |
Gitcito는 git flow CLI가 쓰는 것과 똑같은 gitflow.* git 설정 키를 읽고
써요 (gitflow.branch.master, gitflow.prefix.feature, …). 누군가 이미
git flow init 을 실행해 둔 저장소는 곧바로 인식되고, 여기서 설정한 저장소는
그 뒤에 CLI로도 잘 동작해요. Gitcito는 처음부터 끝까지 평범한 git 명령을 실행해요
— CLI가 설치돼 있을 필요는 없어요.
설정은 그 키들을 쓰고, 통합 브랜치가 아직 없으면 릴리스된 브랜치에서 만들어요. 그 외에는 아무것도 건드리지 않아요. 이름이나 접두사는 나중에 레이아웃 편집에서 바꿀 수 있어요.
시작하기
종류를 고르고, 이름을 입력하고, 시작을 누르세요. 대화 상자는 확정하기 전에 만들려는 브랜치와 그것이 어디에서 갈라져 나올지를 보여 줘요.
feature/search from develop
hotfix/1.0.1 from main
이름은 당신이 입력한 것이고, 접두사는 레이아웃에서 와요.
끝내기
완료야말로 자동화할 값어치가 있는 부분이에요. 반드시 모두 일어나야 하는 여러 단계로 이루어져 있으니까요.
| 종류 | Gitcito가 하는 일 |
|---|---|
| 기능 | --no-ff 로 develop 에 머지하고, 브랜치를 지우고, develop 에 남겨 둬요 |
| 릴리스 | main 에 머지하고, 태그를 달고, develop 에 머지하고, 브랜치를 지우고, develop 에 남겨 둬요 |
| 핫픽스 | main 에 머지하고, 태그를 달고, develop 에 머지하고, 브랜치를 지우고, main 에 남겨 둬요 |
--no-ff 는 의도적이에요. 그 머지 커밋이 있어야 나중에 그래프에서
브랜치가 보이니까요. 없으면 짧은 기능 브랜치는 일직선 속으로 사라져 버리고, 이
모델은 존재 이유를 잃어요.
태그는 <버전 태그 접두사><이름> 이에요 — 기본 접두사라면 release/1.1.0 은
v1.1.0 이 돼요. 릴리스에 태그 달기의 체크를 풀면 건너뛰고, 기본값 이상을
원하면 태그 메시지를 쓰면 돼요.
하지 않는 일
- 더러운 작업 트리는 이 작업을 멈춰요. 먼저 커밋하거나 스태시하세요. 완료는 두 브랜치를 머지하고 HEAD를 두 번 옮기는데, 커밋하지 않은 작업 주변에서 그렇게 하는 것이 사람들이 작업을 잃는 방식이니까요.
- 머지에서 충돌이 나면 전체가 되돌려져요. main 에 머지하는 데는 성공했는데 develop 에 머지하다 충돌이 나면, 그렇지 않을 경우 절반만 끝난 릴리스가 남게 돼요. Gitcito는 모든 브랜치를 원래 자리로 되돌리고 충돌을 알려 줘요. 그 브랜치를 직접 머지하고 충돌 해결기에서 해결하면, 나머지 흐름은 손으로 마무리하시면 돼요.
- 절대 푸시하지 않아요. 완료는 로컬 작업이에요. 준비되면 main, develop, 그리고 새 태그를 푸시하세요 — 동기화를 보세요.
되돌리기
되돌리기 한 번이면 전부 제자리로 돌아가요. 두 브랜치는 이전 커밋으로 돌아가고, 태그는 지워지며, 끝냈던 브랜치는 예전 끝점에 다시 만들어져요. 완료를 부담 없이 시도해 볼 수 있는 이유가 바로 그거예요.
쓰지 않는 게 나을 때
Git flow는 버전이 매겨진 릴리스와 지원되는 운영 브랜치가 있는 소프트웨어에
어울려요. 하루에 여러 번 main 에서 배포한다면 릴리스와 핫픽스 브랜치는 결국 쓰지
않을 격식이에요 — 스택 브랜치나 main 에서 갈라진 평범한 단명
브랜치가 더 잘 맞아요. 모델의 기능 브랜치 절반은 그 자체로도 여전히 잘 작동해요.