브랜치와 수술

Git flow

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

⌘K → Git flow 가 그 사무 처리를 대신해요.

릴리스 브랜치에서 열린 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 에서 갈라진 평범한 단명 브랜치가 더 잘 맞아요. 모델의 기능 브랜치 절반은 그 자체로도 여전히 잘 작동해요.

GitHub에서 이 번역 개선하기