Git 전략 - GanOverflow 회고

Git, 잘 쓰고 계신가요?

Git, 개발의 필수 툴이다. 그러나 초보 개발자들에게 Git을 어떻게 쓰고 있는지를 물어보면, 의외로 (?) commit - push - pull만 치는, 마치 Google Cloud 처럼 사용하는 경우가 많을 것이다.

이번에 GanOverflow 프로젝트를 팀 단위로 작업하며 Git 규칙을 보다 본격적으로 정리할 필요가 있었다. Github Actions와 Docker, Vercel과 Github의 main 브랜치를 묶어서 CI/CD 및 배포 툴을 자동화해서 사용한 것도 이유였지만, 팀단위 작업을 한다는게 컸다.

(대충 그것이 Git을 사용하는 이유니까.. 끄덕짤)

오프라인 미팅을 매일 할 수 있었던것도 아니고, 프런트 - 백엔드를 나눠서 작업한 것도 아니었기 때문에 (모두가 풀스택!), 확실한 작업 규칙이 필요했던 것!

이런 저런 방법론을 찾던 중, Git flow 전략과 Github Flow 전략, Trunk 전략을 찾았다. 우리는 Git flow 를 기반으로 하되, 이 프로젝트의 특성에 맞게 몇가지 개조를 거쳐 작업 규칙을 정했다.

Git Flow

Git flow를 설명하는 글에는 빠지지 않는 그림! 설명하자면,

• master : 가장 메인이 되는 브랜치, 언제든지 배포해도 문제가 없어야 함, 태그로 버전 관리
• develop : 개발자가 마음대로 커밋쳐도 되는 브랜치, 버그 수정 / 기능 구현을 위함. 물론 이것은 브랜치를 파서 커밋 후 Merge 해야 한다!
• feature : 기능 구현을 위한 브랜치. feature/pagination, feature/sign-in과 같이 구현하고자 하는 기능 단위로 브랜치를 생성하고, 완성되면 develop으로 merge 한다.
• hotfix : 작은 버그를 빠르게 수정하기 위한 브랜치. merge 해놓고 보니 예외사항이 있다면, 다시 feature/ 브랜치를 파서 작업하기에 애매한 경우가 아주 많다. 그렇다고 develop에서 직접 수정 후 직접 커밋은 개발 기록을 추적하기에 적합하지 않음. 따라서 hotfix 브랜치를 두고 운영한다.

Git Flow - 장단점

가장 잘 알려져 있고, 많은 팀에서 적용한 전략이다. 처음에 이해하기 까다로울 수 있지만,
(음.. 사실 동의 못한다. 그림만 봐서는 어려울 수 있어도 직접 해보면 체득이 빠르다고 생각함)
의외로 팀 단위 작업에서 자동화 CI/CD가 있을 때 잘 안어울리는 경우가 있는 것으로 보인다.
위 그림에서 빠져있는 것이 바로 코드 리뷰 과정 이기 때문이다. 자동화된 배포가 구축돼있다면 master (혹은 release) 브랜치로 머지되는 순간 배포되는 것이다! 리뷰 과정이 없으면 제대로된 형상 관리가 된다고 할 수 있을까?

Github Flow

그래서 각광받았던 것이 이 전략이라고 한다.

꽤 복잡한 작업규칙이 있는데, 요는 이렇다

• 원격 레포로 Push는 수시로 진행
• 로컬에서 Merge는 지양, PR로 Merge하는걸 지향
• PR 전 코드 리뷰!
• master로 merge 완료 시 자동 배포

Github flow - 장단점

자동화 배포, 팀작업에 가장 적합하지만, 그래도 feature 브랜치나 develop 브랜치, hotfix 브랜치를 사용하는 점이 없으면 아쉽다. 너무 간단하다는 점이 장점이자 단점.

그럼 합치자!

그래서 두 전략을 적절히 합쳐서 적용했다.

1. main 브랜치를 자동 배포 브랜치로 설정했다. (NestJS : 도커+Github Actions, NextJS : Vercel을 물려놓음) main으로 merge할 때는 항상 dev에서만 PR을 날려서 수행한다 ! ex. PR : dev → main. 다른 브랜치에서는 절~~~대로 직접 merge 하거나 PR 날리지 않는다.
2. dev 브랜치가 사실상 Git Flow 전략에서의 develop 역할이지만, main 역할처럼 사용! 태그까지는 못달았지만,, 언제나 배포 가능하게끔 관리했다. 역시나 dev merge 시 무조건 PR을 날려서 코드리뷰를 거쳐야 한다. 코드가 복잡해서 이해가 안될 때 오프라인 미팅을 거치기도 했음 (ㅋㅋ)
   요지는 feature, hotfix, chore 등등 새로운 브랜치를 생성하고 머지하는 기준이 바로 dev이고, hotfix의 소소한 변동사항이 아니라면 절대 직접 merge하지 않고 PR을 통해 코드리뷰를 거친다는 점이다.
3. feature 브랜치 : 기능 단위로 생성, PR을 통해 dev로 merge. 기능 단위로 feat-pagination과 같은 브랜치를 판 뒤에 작업한 뒤 dev로 PR. 사실상 feature라는 이름을 가진 브랜치는 없다! 기능 브랜치들의 집합을 일컬은 것.
4. hotfix 브랜치 : feature와 달리, 핫픽스 하나마다 브랜치를 새로 파지는 않았고, hotfix 브랜치를 항상 dev와 동기화하도록 노력해서 한줄씩 간단한 수정할 때 사용했다. main으로 머지하지 않는것을 주의해야 함. main은 항상 LTS (Long Term Support) 버전처럼 관리했다.
5. 추가로 chore 브랜치도 사용했다. .gitignore 파일을 수정하거나 docker.compose같이 코드 로직은 아닌데.. 기능도 아니고 핫픽스도 아닌 애매한 경우에 이 브랜치를 사용했다. 용례는 hotfix와 비슷함.