팀을 위한 깃 브랜치 전략 공부하기

상황

이번에 우테코에서 팀플을 진행하게 됐다.
팀에서 협업 플로우를 정하는 도중, 깃 브랜치에 대해서 심도있게 토론해본뒤 그 내용을 정리해본다.

선결론 - 깃 플로우와 유사하게 가되, hotfix만 쓰지 말자

깃 플로우?

브랜치 전략 중 하나.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

깃플로우 브랜치들은 위와 같다. 이 중 우리팀에서는 hotfix 브랜치의 경우는 제외하기로 했다.

hotfix는 운영상 최대한 빠르게 해결해야하는 것이다.
hotfix 브랜치를 도입하게되면 merge하는 과정에서 발목을 잡을 수 있다.
hotfix 특성상 안정성이 아닌, 문제 해결을 빠르게 하는것이 우선되기 때문에 hotfix 브랜치에 대해서는 무작정 도입하지 않고 생각해볼만하다.

현재 팀 프로젝트 구조

BE,FE가 한 레포지토리로 된 모노리스 구조

목표

• 어떻게해야 서로 간섭없이 잘 협업하기 좋은 구조일까?

프로세스 생각하기

각자 dev 작업을 하여 상위 브랜치에 (main이라고 가정) merge할것임

• fe만 수정되었는데 be도 함께 pull해야한다

fe/be를 분리하여 브랜치를 작업하자

• fe/dev be/dev 이런식으로 브랜치를 분리하자!

릴리즈

• 프론트엔드 개발자분이 릴리즈를 생략하자는 의견을 내셨다.
  • 몰랐는데, 프론트엔드에서는 보통 로컬에서 작업해서 기능들을 모두 테스트한 뒤에 바로 배포를 한다고 한다.
• 하지만 바로 배포하면 실제 설정이 다르거나 예기치 못한 문제가 생길 수 있기 때문에 release 브랜치를 두는 것으로 결론.

hotfix는?

목적

• hotfix는 지금 당장 빠르게 문제를 해결하는 것이 목적

핫픽스 브랜치를 두지 말자

프론트엔드 입장에서는, 핫픽스가 로컬에서만 동작했다면 이미 해결이 된 것이 보이는데 굳이 hotfix 브랜치를 통할 필요가 없다.

• 속도가 중요한것도 맞아서, 이부분은 합의를 하고 핫 픽스를 한경우에는 코드 퀄리티에 대해서는 후처리를 하는 것으로 합의함

결국

결국 핫픽스와 릴리즈를 도입하다보니 깃 플로우와 유사하게 전략을 가져가게 됐다.
또한 무조건 깃 플로우가 좋은것이 아닌 팀에게 좋은 플로우가 뭔지를 생각해보니 실용적으로 브랜치 전략을 이해하고 재밌었다.

CI/CD?

• CI/CD를 위해 브랜치를 활용하는 것도 좋으나, 일단은 너무 세부적으로 모든것을 다 정하고 가지는 않도록 했다.
• 브랜치나 PR prefix 등 CI/CD에 적용할 수 있는 정보들이 많다.