소규모 팀의 git 브랜치 전략 (Feat. git flow)

안녕하세요. 루브릭랩스 프론트 엔지니어 펄스입니다. 
오늘은 사내 브랜치 전략에 대해 설명해보고자 합니다.
프로젝트를 수행하기 위해서는 여러 개발자들과 협업을 진행하게 됩니다. 여러 개발자들이 한번에 소스코드를 수정하게 되면 버전관리 및 코드관리가 어려워지게 되는 문제가 생기는데요, 이럴때 코드 형상관리 툴인 git을 이용해 이런 문제를 해결합니다.

git을 통해 코드 형상관리를 하는 방법을 브랜치 전략이라고도 하는데요, 많이 사용하는 브랜치 전략으로는 Git Flow와 GitHub Flow가 있습니다.
Git Flow는 기능(feature), 릴리스(release), 핫픽스(hotfix) 등의 작업을 위한 다양한 브랜치를 사용하는 전략으로, 장기적인 프로젝트에 적합합니다. 이 전략은 develop, master, feature, release, hotfix 브랜치를 통해 명확한 작업 흐름을 제공합니다.
GitHub Flow는 더 단순한 전략으로, 하나의 메인 브랜치(보통 main 또는 master)와 기능 브랜치들만 사용하며, 지속적인 배포와 짧은 사이클의 작업에 적합합니다.

-----

현재 우리 프로젝트에서는 운영 전에는 단일 서버에서 하나의 develop 브랜치에 모든 커밋을 쌓아가며 개발을 진행 해왔습니다.  
그러나 서비스 운영 이후, 서버가 운영과 개발로 나뉘면서 이에 따라, 우리는 Git Flow에서 영감을 받아 다음과 같은 새로운 전략을 적용했습니다:

• ‍master : 운영계에 올라갈 코드들만을 관리하는 main 브랜치, Git Flow의 release 역할
  ‍
• ‍prd: 운영에 실제로 배포가 되는 브랜치, Git Flow의 master 역할
  ‍
• ‍dev: 운영 배포 전 테스트가 필요한 개발건들을 가지고 있는 브랜치, Git Flow의 develop 역할

이 전략을 선택한 이유는 운영 환경과 개발 환경이 분리되면서 브랜치 관리의 체계성과 안정성을 강화하고, 배포 전 테스트 과정을 명확히 관리할 필요가 있었기 때문입니다.

‍
그렇다면 v1.0.1의 prd 배포와 v1.0.2 개발, 그리고 배포 후 진행되는 플로우에 대해 설명드리겠습니다.개발 요청 A, B, C가 들어왔다고 가정해보겠습니다.
개발자는 dev 브랜치를 기준으로 A, B, C 기능에 대한 개별 브랜치를 생성하여 각각 개발을 완료한 후, dev에 병합합니다.

이 시점에서의 Git 그래프는 다음과 같습니다.
아직 master에는 A, B, C에 대한 개발 내용이 반영되지 않은 상태입니다. 이후, 프로세스팀에서 개발된 A, B 기능을 테스트 완료한 후 운영 서버로의 배포 요청이 들어옵니다.
이제 수행해야 할 작업은 아래와 같습니다:

1. dev에 있는 A, B 커밋을 master에서 새로운 브랜치를 생성하여 cherry-pick으로 가져옵니다.

2. 가져온 A, B 커밋을 master에 병합합니다.

3. master를 prd에 병합합니다.

4. prd에서 새로운 버전 태그를 생성한 후 배포를 진행합니다.

5. dev와 master를 prd와 동기화합니다.

이 1~5번 과정이 사실상 개발 후 배포 프로세스의 전부입니다.

(1~2번)

dev에 있는 commit1, commit2를 배포해야하는 상황

• master branch에서 branch 생성
  ‍
• git cherrypick commit1고유넘버 commit2고유넘버 를 수행

• 이후, git push upstream develop/bmy1320/20240708 로 올린 뒤 PR 만들어 master에 머지 하기

‍
‍

여기까지 진행된 시점의 git graph는 위와 같습니다.

(3~4번)

이제 배포할 내용 A와 B가 담긴 master를 prd에 병합한 후, 배포할 내용의 태그를 생성합니다.
이때, 정확한 태그 생성을 위해 반드시 prd 브랜치를 기준으로 태그를 생성해야 합니다. (master가 아님)

(5번)

이제 남은 작업은 master와 dev를 prd와 동기화하는 것입니다.
master에서는 prd를, dev에서는 master를 rebase 해주면 됩니다. 각 브랜치를 동기화하는 Git 명령어는 다음과 같습니다.

대부분의 경우, 아래 명령어 순서대로 진행합니다:

1. git checkout master - master 브랜치로 이동
   ‍
2. git rebase upstream/prd - prd 브랜치를 rebase
   
3. git push upstream master - master 브랜치를 최신 상태로 업데이트

‍

다음으로 dev 브랜치 동기화를 위해 아래 명령어를 사용합니다:

1. git checkout dev - dev 브랜치로 이동
   ‍
2. git rebase upstream/master - master 브랜치를 rebase
   ‍
3. git push upstream dev - dev 브랜치를 최신 상태로 업데이트 (기존 dev에 다른 기능이 포함된 경우 force push 필요. 이때는 여러 차례 확인 후 진행하며, force push는 항상 신중히 수행해야 합니다.)

이로써 모든 브랜치가 최신 상태로 동기화됩니다.

‍

가장 이상적인 브랜치 모습

‍

• 해당 브랜치 모습처럼 깔끔하게 유지하는 것이 이전 버전 정보 및 커밋 정보들을 파악하기 용이합니다.
  ‍
• 흐름이 비교적 복잡하지 않고 단순 합니다.
  ‍
• 깃 그래프가 단순하기 때문에 그래프만 봐도 어느 버전에 어떤 기능들이 배포되어있는지 쉽게 파악하기 용이합니다.
  ‍
• 브랜치를 단순하게 유지하려면 브랜치 정리에 신경 써야 합니다. 병합된 브랜치는 바로바로 정리하세요!

‍

이 브랜치 전략은 3명 이하의 개발자가 협업할 때 효과적인 방식입니다.
그러나 Git 그래프의 지속적인 최신화와 동일 파일의 동시 수정 금지 등 주의해야 할 점들이 있어, 인원이 많아질수록 적용하기 어려울 수 있습니다.
따라서 이 전략은 각 팀의 상황에 맞게 유연하게 활용하는 것이 중요합니다. 모든 팀에 보편적으로 적용되는 정답이 아니라, 팀의 특성과 요구에 따라 조정하여 사용하는 것이 바람직하다는 점 잊지마세요!
읽어주셔서 감사합니다.