깃 브랜치 전략 현실판 회사 > IT이야기

서 협업하다 보면 브랜치 전략 때문에 머리 싸매는 경우 많음. 구글링하면 Git Flow, GitHub Flow, Trunk 기반 개발 등 이름 멋진 이론은 많은데, 실제로는 팀 상황에 맞는 하이브리드가 제일 현실적이더라. 특히 배포 주기랑 QA 프로세스에 따라 전략이 완전 달라짐. 예를 들어 매일 릴리즈하는 팀은 trunk 기반이 딱인데, 두 달에 한 번 배포하는 팀은 release 브랜치 없이는 답이 없음. 내가 해본 팁은 브랜치 이름 규칙부터 단순하게 만들어야 한다는 거. 긴 규칙 만들면 다들 기억 못 하고 결국 엉망이 됨. feature, hotfix, release 정도만 정해두고 나머지는 PR 제목이나 태그로 구분하는 게 훨씬 덜 피곤함. 그리고 머지 전략도 팀마다 합의해야 하는데, squash로만 갈지, rebase까지 허용할지 초반에 못 박아두면 나중에 기록 지저분해지는 거 방지됨. 마지막으로 신입 합류했을 때 브랜치 전략 문서화가 무조건 필요함. 그냥 구두로 설명하면 다 까먹고, 문서 없이 서로 다른 해석으로 브랜치 따버리면 카오스 남. 문서에다 예시까지 들어두면 신규 멤버도 바로 적응 가능하고, 리뷰할 때도 쓸데없는 컨벤션 얘기 줄어듦. 결국 브랜치 전략의 핵심은 '팀 모두가 똑같은 규칙으로 행동해야 한다' 이거 하나임....

좋아요0 이 글을 좋아요하셨습니다