Git 브랜치를 어떻게 운용할 것인가에 관한 방법론에 대해서 보통 아래 3가지 전략이 언급된다.

• Git-Flow
• Github-Flow
• Gitlab-Flow

이 글은 이 전략들 중 Git-Flow에 대한 설명이다.

브랜치 운용

Git-Flow 전략은 아래와 같은 5개 종류의 브랜치를 사용한다.

1. master(또는 main)
2. develop
3. feature
4. release
5. hotfix

• master
  production에 배포하는데 사용하는 브랜치다.

• develop
  최초 브랜치 전략 도입시 master로부터 생성하고 개발한 기능(feature 브랜치)들을 모아두는 브랜치다.

• feature
  develop으부터 생성해서 개별 기능을 개발할 때 사용하고, 기능 개발이 완료되면 develop에 머지하는 임시 브랜치다.
  당연히 동시에 여러 기능을 개발하면 여러개의 feature 브랜치가 생긴다.
  따라서 해당 기능을 요약하는 영단어를 사용해 feature/socialLogin, feature-socialLogin 과 같은 형식으로 브랜치 이름을 정한다.
  (슬래시를 사용하는 방식을 추천한다.)

• release
  develop에 개발된 기능들이 모이면(=feature 브랜치들이 develop에 머지되면) develop으로부터 생성해서 QA를 수행하고, QA가 종료되면 master에 머지해서 production에 개발한 기능을 반영하는 임시 브랜치다.
  QA 과정에서 수정할 사항이 생기면 release에 직접 수정하고, 수정된 내용이 develop에도 반영되야하기 때문에 develop에도 머지해야한다.
  release가 master에 머지될 때마다 production 버전이 하나씩 올라가게 된다. 따라서 master 머지 후 버전 tag를 붙여두는 것이 좋다.
  (release가 master에 머지되면 즉시 production에 배포되야 하는 것이 원칙이다.)
  develop으로부터 release를 언제 생성해야하는가 즉, 얼마만큼의 기능을 이번에 production에 반영할 것인가하는 문제는 서비스 운영 관점에서 판단하기 나름이다.

• hotfix
  production에 긴급 수정을 요하는 상황이 생긴 경우 master로부터 생성해서 코드 수정 후 master에 머지하는 임시 브랜치다.
  수정된 내용이 develop에도 반영되야하기 때문에 develop에도 머지해야한다.
  feature과 마찬가지로 수정 내용을 요약하는 영단어를 사용해 hotfix/loginErr, hotfix-loginErr과 같은 형식으로 브랜치 이름을 정한다.
  (역시 슬래시를 사용하는 방식을 추천한다.)

임시 브랜치들은 사용 목적을 다하면(=머지가 완료되면) 삭제한다.

머지를 할 때는 커맨드 명령어를 사용한다면 --no-ff 옵션을 사용하고, 소스트리를 사용하다면 'fast-foward가 가능해도 새 커밋으로 생성' 옵션을 체크해서 머지 커밋을 남기는 것이 기록 추적과 관리에 용이하다.

장점

1. 보수적인 운용 방식으로 배포 사고가 줄어든다.
2. proudctoin, staging, qa, develop과 같이 목적별로 상태가 다른 다수의 서버를 운영할 때 용이하다.

단점

1. 브랜치가 다소 복잡해지는 경향이 있다.
2. 완성된 기능을 선택적으로 배포하지 못해 유연성이 떨어진다.

결론

위와 같은 Git-Flow 방법론을 반드시 똑같이 적용할 필요는 없다.
회사마다 팀마다의 상황과 니즈에 맞춰 Git-Flow 전략을 변형하여 사용하면 될 것이다.

참고

1. Vincent Driessen의 원문 : https://nvie.com/posts/a-successful-git-branching-model
2. OS의 패키지 매니저로 git-flow를 설치하면 커맨드 명령어를 사용해 Git-Flow 전략대로 브랜치를 사용할 수도 있다. https://github.com/petervanderdoes/gitflow-avh

PS.
틀린 내용이 있거나 보완할 점이 있다면 댓글 환영입니다.