[git] 멀티 브랜치 전략 탐색 (현재 다니고 있는 회사용)

언젠가는 제때 정리해라, 제발..

개요

보통 멀티 브랜치는 feature, develop, master, hotfix로 많이 쓴다. 예를 들어 야구예매시스템 개발과정에서 로그인 기능은 feature/login, 결제기능은 feature/payment으로 말이다. 여러 기능들을 멀티 브랜치로 관리하면, 필요한 기능을 선택적으로 합쳐서 새로운 것으로 만들기가 용이하다.

 

 

필요성

멀티브랜치 사용에 대한 필요성을 느끼게 된 계기는 merge가 제대로 되지않는 문제를 겪고 있기 때문이다. 처음에는 단일 브랜치를 사용하다가, 국가별로 프로젝트를 나누어서 사용하려고 멀티 브랜치로 변경되었다. 그리고 자주 업데이트 되는 master 브랜치에는 기존에 작업했던 내용이 정상작동하지만, 'A 이름'을 가진 브랜치는 아니다.
원인은 아직 모르지만 야매로 브랜치를 진행하고 있는 것 때문임은 분명하다. 그래서 멀티브랜치 전략에 대해 제대로 공부하고, 싸피 경험을 빗대어서 지금 회사에서 최적인 것으로 결론을 내보려고 한다.

+ [사담] 이건 자랑인데, 기술적인 부분(aws 활용, CI/CD 등)으로 우리팀을 일등시켰음. 그러니 잘해낼거라고 믿음.

 

현재 환경 탐색(요구사항 파악)

1. 기능에 대해 공통으로 남아야하는게 존재함.

  예를 들어서 Dockerfile은 C/C++ 소스코드 빌드를 위해 모든 브랜치에 대해 동일하게 적용되어야함.

2. 다른 브랜치에서 일부 기능들을 merge 해야함.

3. 국가별로 단일 브랜치로 개발을 진행함 가지게 됨.

결론

기능을 개발할 때마다 feature 브랜치로 분기해서 개발하는식으로 진행을 설득해야한다.

만약 국가별 단일 브랜치들이 master 브랜치로부터 차이점이 계속 발생한다면, 이 단일 브랜치들을 유지하며 개발하는 것은 어려움이 있다. 기능 개발을 할 때마다 master 브랜치에서 분기하고 완료 후에는 해당 브랜치를 삭제하는 방식으로 진행하면, 각 국가별 단일 브랜치와 master 브랜치 간의 차이점이 줄어들 것이다. 이로 인해서 변경사항이 기존보다 적어지기 때문에, merge가 제대로 안되더라도 원인을 빨리 파악해서 야근을 만드는 폭탄을 없앨수있다.

+ [단일 브랜치 기반] 팀원이 본인것 외에 다른 것은 제대로 확인을 하지 않은채 merge를 하게 되면, 나는 이유도 모른채 집에 못가는 경우가 있었다. (여전히 단일 브랜치로 하는 것이 답답하지만.. 어르신들이 변화는 시도하지도 않고 나이로 찍어누르는데.. 조금씩 설득해서라도.. 개선해야지..)

 

 

 

참고 자료

https://blog.hwahae.co.kr/all/tech/9507