저만의 생각입니다.
깃 브랜치 전략은 사실 상황마다, 팀마다 너무 다르게 흘러갑니다. 가장 정답이라고 생각했던 전략이 생각보다 팀의 전진을 가로막는 전략일 가능성이 높았습니다. 그래서 최대한 글을 보수적으로 작성하겠습니다.
Main / Dev 브랜치는 필수
main은 배포 환경에서의 코드입니다. 이 브랜치에 직접 푸시하는 상황 같은건 존재하지 않도록 만들어야합니다. 배포 환경에서의 환경 변수 설정이나 클라우드 서비스 운영 전략은 개발 환경과는 매우 다르기 때문에, 반드시 분리되어야한다고 생각합니다.
Feat 브랜치는 과연 필요할지…
Feat/… 브랜치는 정말 상황마다 유동적으로 적용해야하는 브랜치라고 생각합니다. 비슷한 파트의 코드를 구현하는 사람들끼리만 feat/… 를 통해 동일한 브랜치 흐름에서 좀 더 세분화한다던지 해야지, 처음부터 “기능이 다르니 feat를 사용해야지”같은 전략은 팀의 개발 속도를 낮추는 행위라고 봅니다.
TBD + Main/Dev 브랜치 전략은 어떨지
TBD(Trunk-Based Development)를 봤습니다. 단일 브랜치에 짧은 기간마다 자신의 코드를 통합하는 전략이었는데, 제 경험상 배포가 생각보다 수월했던 적이 없었습니다(숙련자가 없으면). 일정 수준 개발이 이뤄지면 CD 전략도 구축해야 뒤에 가서 배포로 문제가 생기지 않았던 것 같습니다. 그래서 dev 브랜치를 기준으로 TBD를 진행하는 식이면 어떨까 싶습니다.