대부분의 프로젝트를 만들면 가장 필수고 초기 세팅과정에 Git이 빠질 수 없다.
소스 버전관리로 사용되는 Git은 개인프로젝트나 팀프로젝트에서 중요한 역할을 한다.
버전을 쉽게 관리하고, 히스토리로 코드의 의도도 파악하고, 서로 코드의 수정을 쉽게 관리할 수 있고 심지어 코드를 짠 사람을 추적할 수 있다.
이처럼 뺄 수 없는 관리 툴이 되어온 Git을 여러명이 작업을 할 때, 일종의 규칙을 정하여 Flow를 정립하여 사용하는게 일반적이었고, 그렇게 해야하는 걸로 알았다.
이 포스트는 Git의 명령어와 사용 방법을 포스팅하는 것은 아니다. git flow 라는 어떤 브랜치 전략을 가지고 기본적으로 알려진 'main, release, develop, hotfix, feature 의 git flow를 써야하는가' 다.
확실히 Git Flow 를 도입하면 일종의 규칙이 생겨 팀원간 작업의 방식이 달라진다.
서로 충돌을 발생하는 것을 사전에 막을 수 있고(100%는 아니지만), 생각보다 유동적으로 코드 버전관리를 할 수 있다.
하지만 요즘들어 이런 생각을 한다.
깃플로우가 최선인가?
우리 팀은 과거 백엔드개발자 3명에서 현재는 8명까지 늘었다. 레거시 레파지토리는 그만큼 동시 작업인원이 늘어나고있다. 이런 상황에서 레파지토리 버전관리는 필수가 되었다.
먼저 우리팀이 고수하는 방식은 main, develop 브랜치이다. 점점 사용빈도가 늘어나니 개인적으로 release 를 고려했다.
우리회사의 Git 사용 방식은
- merge 는 Contributor가 한다.
- 코드 관리를 잘하자.
- PR은 선택 스스로의 코드에 책임을 갖자.
이렇게 개방적인 스타일이다보니 문제가 생겼다.
누군가가 develop 에 배포할 수 없는 커밋이 있다.
배포하기 위해선 모든 컨트리뷰터에게 물어봐야 한다.
모르는 코드로인해 PR을 기다려야한다.
나는 백엔드 채널에 이런 문제점을 release 로 해결하자는 의견을 올렸다.
뜨거운 토론 끝에 의견이 일치됐다.
우리의 깃플로우
- 개인 작업 브랜치 커밋 관리를 잘한다.
- develop 브랜치는 신뢰 가능한 커밋만 머지한다.
- 최소 1일 1배포한다.
- 문제를 놓친경우, 롤백을 빠르게한다.
- 레거시 시스템에서 신규작업을 피한다.
- 불가피한 상황에서는 작업자가 채널에 공유 주시고, 논의를 통해 release 등 임시 브랜치, 메인 브랜치 관리 등 상황에 맞게 작업을 한다.
- 추후 서비스플랫폼팀에게 기능을위한 서버 개설요청을 드린다.
당연하지만 쉽게 지켜지지않는 규칙이다.
어쩌면 우리는 기본적인 방식을 지키지않아 문제를 얻은 것이다.
지키기만했으면 이런 고민조차 할 시간을 아끼지 않았을까.
지속적인 배포를 가장 중요하게생각하고 서비스 코드상 바로 live 환경에 올려야한다.
오히려 레거시 기반으로 장기간 작업은 코드만 꼬일 뿐이다. 그렇기에 그날 작업한건 모두 호환성을 유지하며 그날 배포가 끝나야한다.
또한 지속적으로 MSA 를 지향하는 작업스타일로 레거시 시스템에서는 신규 작업을 피한다. MSA의 단점이 파편화되어있는 시스템을 유지보수하기 어렵다지만, 사실 하나에 몰려있는 코드보단 리스크가 적다고 생각하며, 코드의 충돌도 훨씬 낮다.
기존 레거시는 node.js로 express 프레임워크기반이라 오류 발생가능성도 빌드단계에서 찾기 어렵고, kotlin spring 으로 넘어가는 과정에서 최대한 오류를 피해 git 관리를 쉽게하는게 최선이다.
깃플로우는 서로 코드관리에대해 방향을 제시해주는 것이지만 너무 허들이 높은 관리플로우는 오히려 작업의 부담감만 증가시켜준다.
최대한 깔끔하고 서로 신뢰가는 코드로 작업 상황이 공유가 되는 환경이면 main-develop 만으로 모든 작업이 수월하게 끝날 것이라 생각한다.
