Merge 전략
이전까지는 PR로 브랜치를 병합할때, merge & no-ff(fast-forward) 옵션을 사용해서 merge commit 까지 남기는 방식을 선호해왔다.
이유는 명확했는데, branch graph 로 commit 내역을 보는게 작업 흐름을 가시적으로 파악하기 수월해서였다.
반대로 squash merge 는 모든 commit 을 하나의 commit 으로 만든다는 점에서 작업 흐름이나 트래킹이 어렵게 만든다고 생각했고, 장점이 크게 없다고 생각했다.
그리고 (물론 이건 나의 잘못이기도 하지만) 이전까지는 혼자 작업을 하면서 하나의 작업단위(PR)의 사이즈가 컸고 작업과 동시에 유지보수해야할 코드도 있다보니, 단순히 작업에 대한 commit 뿐 아니라 일부 refactor 관련 commit 들도 겸사겸사 포함되면서 모든 작업사항을 단일 commit 으로 만든다는것에 대해서 거부감이 컸던것도 사실이다. (작업한 내용이 굉장히 많은데 단일 commit 으로 만들어 버리는 경우, commit 단위의 에러 트래킹이 거의 불가능해진다.)
작업 환경의 변화
같은 단일버전의 코드베이스만 유지해야하는 b2c 어플리케이션의 경우에는 버전 하나에 대한 서브 브랜치(main, develop, ...)들과 작업 브랜치들(feature, hotfix, release ...)만 가져가면 되고, 작업자의 수가 적을수록 작업 브랜치의 수도 줄어들게 되면서 GUI 환경에서 branch graph 를 살펴보고, 작업 흐름을 따라가기에 편한 환경이 만들어진다.
이런 작업 흐름을 따라가기 편한 상태에서, 모든 commit 이 남아있어서 commit 단위로 히스토리 추적이 크게 어렵지 않다.
그런데, 센드버드에 들어오면서 정 반대의 상황에 마주하게 됐다. 작업자가 많았고, 유지해야 할 버전이 여러개였으며, 브랜치가 굉장히 많았다.
그리고 이런 상황에서 내가 사용하던 방식으로 관리되고 있는 repository 의 브랜치 가시성이 얼마나 확보되지 않는지도 직접 목격할 수 있었다.
버전에 대한 서브 브랜치가 버전별로 존재해야하고, 작업 브랜치도 각 버전별+작업자의 수만큼 늘어나게 된다.
이렇게 되면 GUI 환경에서 branch graph 를 살펴보는게 굉장히 어렵게 되면서 작업 흐름 또한 따라가기가 어렵고, commit 단위의 히스토리 추적보다는 main branch 에서 merge commit 단위의 히스토리 추적을 할 수 밖에 없다.
물론 이건 비단 비즈니스용 sdk 한정의 문제가 아니라 대규모 오픈소스나 서버쪽에서도 마찬가지일 것이라고 생각한다.
다만 나는 이런 환경 위에서 직접 작업하며 목도할 기회가 없었을 뿐이고, 이번 기회에 목격하게 됐다.
작업 환경에 따른 Merge 전략의 필요성
조직의 규모가 커지면서 역할은 세분화되고 작업 관리를 도와주는 전문 인력들도 생겨난다.
작업자의 수도 함께 늘어나게 되고, 이때문에 작업은 점점 명확하고 세분화된 작은 단위로 변화되어 간다.
즉, squash merge 가 유리한 상황이 된다.
작업 단위 자체가 명확하고 작다보니, 하나의 작업에 포함된 commit 들을 단일 commit 으로 만드는데 부담이 사라지게 되고
squash merge 된 단일 commit 단위의 히스토리 추적이, 이전처럼 부담스럽지 않은 수준이 된다.
작업 브랜치들을 모두 가져가지 않게 되면서, branch graph 상에서 GUI 상에서 버전별 브랜치와 서브 브랜치의 가시성 또한 확보할 수 있다.
역시 이해하는데는 직접 겪어보는게 최고인 것 같다.
