[Git] 사내 Git branch 관리 세미나 및 정책 수립

본 글은 야간모드에 최적화 되어있습니다. 우측 상단에서 해 혹은 달모양을 클릭시어 velog 설정을 야간모드로 해주시면 더욱 편안하게 읽으실 수 있습니다.

🤔 Session Date : 22.06.30
👊 Decision Date : 22.07.05

우리 회사는 스타트업이라서 시니어분들이 계실때 사용했던 git 방식을 그대로 사용했다.

시니어분들이 나가시고 나신 후로는 그 방식을 그대로 사용하다보니 서비스가 점차 커지면서 git이 무분별하게 사용되어갔다.

시간에 쫓기다보니 테스트코드도 점차 희미해져가서 운영계 배포시에 Critical한 버그가 지속적으로 발생하기 시작해버려서, 개발자들간에 코드품질과 git 정책을 다시 한번 점검하고 논의 할 필요가 있다고 느껴지고 있던 터였다.

그렇다보니 다른 큰 곳들이나 주로 git branch를 관리하는 곳들은 어떻게 관리가 이루어지는지 궁금증이 들어서 대기업이나 주로 사용하는 git branch 관리전략을 따르되 스타트업인 만큼 우리 프로세스에 맞는 전략으로 조금 수정을 해서 세미나를 열고 의견을 들어보면 어떨까 싶었다.

첫번째로는 개발팀에게 세미나를 진행하기 위해, 개인적으로 git branch 전략에 대해서 공부했던 내용들을 작성해보았다.

Git branch가 가지는 의미

우선은 git branch 관리를 위해서는 branch 별로 정확한 의미와 그 용도를 한번 다시 파악하고 싶었다.

branch라고 하면 개발자들이 항상 기능을 구현하고, 관리하고, merge 혹은 pull request를 통해 합쳐지고 코드프리징이 이루어지는가 하면 핫픽스가 이루어지기도 하는 일련의 개발과정이 보여지는 곳이다.

실제로도 gitlab 기준으로 각 레포지토리의 Repository > Graph 항목을 보게 되면, 어떠한 branch에서 어떤 내용들이 누가 merge/pull을 했는지 그래프 형태로 드러나게 된다.

그렇기 때문에 브랜치의 관리는 더욱 중요하다고 생각한다.

보통 우리가 쓰는 github, gitlab 등은 아래와 같이 기본 브랜치가 존재하고 있다.

각각의 Git branch들의 의미와 Git Flow

• main(master)
  git 프로젝트 생성시 가장 시작이 되는 branch이자, Back-bone 같은 역할을 해주는 중심 기점 브랜치이다.

  원래 master라는 이름이었는데, git에서 요새 문제되고있는 흑인인권문제를 의식한 것인지 master-slave 라는 관계를 의미하는 것처럼 내포하게 되어서 main 이라는 이름이 기본으로 바뀌게 되었다고 한다.

  (회사에 입사할 당시부터 master로 사용하고 있던터라 나도 모르고 있던 사실이었는데 이번에 git branch 전략을 세워보면서 알게된 사실이다.)
  
  

그리고 확장되는 브랜치 개념들로는 아래와 같은 개념들이 존재한다.

• feature
  일반적으로 '로컬 브랜치' 혹은 '개인 브랜치'로 이해하면 편한 브랜치이다.
  기능의 구현을 담당하고, 브랜치명의 경우에는 팀마다 컨벤션을 정하거나 할 수 있지만 일반적으로는 feature/{구현기능이름 혹은 함수이름}으로 짓는것이 일반적이라고 한다.

  개인 브랜치의 경우에는 일반적으로 아래에서 설명할 develop 브랜치에서 생성하고 어디가 되었던 merge를 실행하게 되면 원격 레포지토리에서는 항상 삭제하는것이 원칙이다.

• develop 혹은 dev
  develop 혹은 dev 라고 명명하는 경우가 많고, 개발 환경이 여러개인 곳들은 1개의 브랜치로 구성되지 않고 develop-{development_env_name} 혹은 dev-{development_env_name} 형태로 여러개가 존재한다고 한다.

  develop 브랜치는 우리가 실제로 개발한 내용들이 "개발 서버"에 배포되는 브랜치라고 보면 된다.

  실제 운영환경에 배포되기전에 개발되는 모든 기능과 테스트가 여기에서 이루어지는 브랜치이다.
  feature 브랜치들은 이 develop 브랜치에 합쳐지게 되고, 각각의 feature들이 모여 배포시점에 하나의 배포 버전을 이루게 된다.

• release 혹은 stage
  팀 마다 지정하는 이름이 다르지만 일반적으로 release, stage라는 이름을 많이 사용한다.

  브랜치명은 일반적으로 release-{release_version or Tag} / stage-{release_version or Tag} 형식으로 지정된다고 한다.

  팀이 운영하는 개발 주기 혹은 기능 개발이 모두 끝나 develop 브랜치에 전부 merge가 된 상태라면 해당 내용을 가지고서 release/stage 브랜치로 merge하여 올리게된다.

  해당 브랜치에서는 운영 환경에 배포되기 전에 릴리즈 버전을 관리하고, 최종 테스트가 이루어지는 곳으로 해당 환경에서 QA, 버그 픽스등이 이루어져 운영 배포가 준비되었다고 판단 하면 아래의 운영 환경 브랜치로 배포하게 된다.

  release/stage 브랜치는 develop/dev 브랜치를 기준으로 생성되거나 merge되고 해당 브랜치에서 발견된 버그 내용은 당연하겠지만 아래에 작성할 hotfix 브랜치로 관리 후 develop/dev 브랜치로도 머지하여 코드를 동일하게 유지한다.
  

• main/production/prod
  가장 중요한 브랜치이자 핵심이 되는 브랜치이고, 개념도 회사,팀 별로 다른 브랜치이다.

  일반적으로는 main 브랜치는 위에서 설명했듯 Back-bone의 역할을 하는 최고 단계의 브랜치이기때문에 해당 브랜치 자체를 운영환경 브랜치로 사용하는 곳도 있고, main 브랜치는 main 브랜치 개념으로 그대로 두고, production/prod 브랜치를 별도로 생성해 운영하는 곳도 있다고한다.

  후자의 경우에는 production/prod 브랜치에 배포를 진행하고 나서 main 브랜치에 해당 내용을 같이 merge 하는 것으로 코드를 유지시키는 것으로 사용한다고 한다. main 브랜치가 운영계 브랜치의 백업 역할이면서 정말 코드 이력만 관리하는 저장소 같은 개념으로 사용되는것이다.

  release/stage 브랜치가 merge 되어 해당 개념의 브랜치로 배포가 되기 전까지는 당연하게도 운영환경은 이전 버전의 소스코드가 배포되어있는 상태이다.
  

• hotfix
  배포된 소스코드에 버그 사항이 발견되면 생성하여 관리하는 브랜치로, 브랜치명은 hotfix-{branch_name}으로 지정된다.

  release 브랜치에서 QA 중 발견된 내용들은 release 브랜치를 기준으로 하여 생성하여 처리하고, 해당 단계에서도 미처 발견되지 못한 버그 사항이 production 단계에서 발견되는 경우에는 각 운영환경에 맞는 최고단계 branch를 기준으로 하여 hotfix 브랜치를 생성하여 관리한다.

  수정이 완료되면 당연하게도 develop, release, production 세 환경을 가진 브랜치에 모두 반영하여 코드를 동일시 한다.

---

Github / Gitlab Flow

Github Flow

github flow는 위에 설명한 전체적인 branch의 관리가 너무 복잡하다고 생겨난 체계로, 모든 내용이나 버그픽스등을 항상 main에 merge 하는 전략이다.

즉, 어떠한 내용이 되었건 main이 항상 기준이며, 각 기능은 feature 브랜치로 관리하는 건 동일하지만 모든 수정사항은 위에서 설명했던 develop, release, hotfix등의 브랜치 관리없이 오로지 main에만 업데이트 된다.

개인 토이프로젝트로 많이 이용되는 github를 사용하는 경우와, 프로젝트 인원이 적은(1~3명)정도의 과정에 적합 하다고 생각한다.

Gitlab Flow

gitlab flow는 과도하게 복잡한 git flow를 조금 간략화 시켜 적용한 flow 형태이다.
기본적으로 feature - main을 가지고 동작하는 github flow에 운영 환경 하나를 추가해서 production 브랜치를 가지고서 개발하는 flow라고 생각하면 된다.

1. feature 브랜치에서 기능을 개발하여 main 브랜치에 merge를 한다.
2. main 브랜치에서 QA 및 버그픽스를 진행한다.
3. main 브랜치에서 준비가 완료되면, production으로 배포한다.

위와 같이 3가지 과정을 반복적으로 거치면서 개발하고, main 브랜치가 develop, release 브랜치 역할을 하며, 운영계 환경만 나누어서 따로 production으로 관리한다고 이해하면 편하다.

1~10명정도가 진행하는 동아리형식의 프로젝트 혹은 소규모 스타트업에서 적용하면 좋을 듯한 방법 이라고 생각했다.

우리는 어떤 브랜치 전략을 취해야할까?

우리 회사의 기존 브랜치 사용 전략

git flow에 대해서 알기 전에는, 우리 회사에서 어떤 전략을 취하고 있는지 몰랐다.

각 flow와 branch의 의미에 대해서 학습하고 나니, 대충 세가지 flow를 섞은 느낌을 취하고 있었다.

개발자 각각의 local-branch 를 통해 기능을 개발하고 main으로 모아서 develop환경을 테스트하고, production 환경으로 배포를 진행하는 과정을 취하고 있었다.

1. local-branch에 대한 fix 내용이나 개발내용은 main으로 모두 적용하는 건 github flow에 해당했고,
2. develop 환경과 production 환경이 나누어져 있는것인 git flow이자, gitlab flow이기도 했다.

여기서 우리는 stage(release) 브랜치도 존재했지만 stage 환경이 구성되어있지 않아 사실상 production 배포전의 백업용으로 사용하고 있었다.

세가지가 중구난방으로 섞여있다보니 개발자간의 merge-conflict도 잦아지고, 버그가 발생하는게 당연할 수 밖에 없겠다는 느낌이 들었다.

새롭게 고민한 맞춤식 git branch 전략

여러가지 방법을 섞어서 사용하고 있던 것이라는 것을 깨달았다보니 우리가 현재 하던 방식을 최대한 해치지 않으면서 git flow를 따라가보고자 했다.

그래서 위 3가지 방법에 대한 내용을 통해 우리가 최대한 사용하고 있는 방식을 벗어나지 않되, 효율적인 flow를 찾아보자고 개발팀에게 제안했고, 개발팀의 의견을 모아 수정을 거친 끝에 아래와 같은 flow로 의견 일치를 일궈낼 수 있었다.

1. 스프린트 주기에 대한 개발 적용 및 main 브랜치의 역할 변경

• 기존 방법
  main 브랜치 -> github flow에서의 main 역할
  develop 브랜치 -> git flow에서의 develop 역할
  production 브랜치 -> gitlab flow에서의 production 역할
  

• 변경한 방법
  main 브랜치 -> production과 동일한 역할을 하며, stage 환경이 없기때문에 유명무실한 stage 브랜치를 대체 하여 사용하기로 결정
  develop 브랜치 -> 기존에 main 브랜치에 넣어서 dev에 한번에 올려 테스트했던 것을 버리고 dev에는 feature 브랜치에서 로컬테스트가 완료된 경우 dev로 바로 적용시켜 테스트
  production 브랜치 -> 기존과 동일
  

git flow에서 release브랜치에서 hotfix를 따는것을 dev branch로 내려서 가져오고, main 브랜치의 역할을 github flow의 역할에서 우리만의 역할을 지정해서 바꾼것이다. 우리는 기존에 main 브랜치를 굉장히 중구난방하게 쓰고있던 터라 그 역할을 dev와 바꿔 적용했다고 보면 될 것 같다.

즉, dev 브랜치에서 바로바로 수정을 하고 dev 브랜치에서 최대한 bug가 없게 한 후에 main과 production으로 배포를 하자는데 의의를 두는 것이기때문에 feature 브랜치에서의 테스트가 굉장히 중요해졌음을 의미하기도 한다.

위의 사유로 인해 "개인의 테스트코드 및 테스트 케이스의 세분화 능력 향상 도모가 된다." 라는 것도 한 몫하게 되었다.

그리고 추가적으로 git의 approval 기능을 활용해서 코드리뷰를 조금더 확실하게 진행하기로 했다.
당장에 적응하기는 어려울 수 있곘지만, 각각의 feature 브랜치에 대해서 dev로 머지가 될 때 해당 코드에 대해서 확인하여 approve를 찍고 문제가 있다면 댓글로 남겨주는것을 도입해보기로 했다.

해당 세미나를 개최하고 git flow에 대해 공부하여 통일시킨 이후로는 FE / BE 개발자간에 의사소통도 더 원활해졌다.

---

마무리

개인적인 의견으로는 확실히 많이 쓰이는 방법들이 좋다고 생각한다.

위에 기술한 각각의 flow들에 적었던 것처럼 github flow는 개인 혹은 5인 이하의 팀원으로 진행되는 프로젝트에 적절하고, gitlab flow는 스타트업 혹은 소규모 프로젝트에서 좋은듯하다.

그리고 어지간한 큰 기업들이면 각자의 git flow가 있을 것으로 생각한다. 그래도 위에서 보인 가장 기초적인 git-flow를 크게 벗어나지는 않지 않을까 싶다.

그럼에도 우리는 스타트업이라는 회사의 특성상 효율적이고 독창적인 방법을 항상 추구해야하기 때문에
기본틀을 지켜보면서도 우리만의 방식을 취하는 것으로 가닥을 잡았다.

공식은 항상 옳지만, 가끔씩은 이렇게 이점만 골라서 새로운 방법을 모색해보는것도 좋은 것 같다. 👊