브랜치 .Refactoring

 

리팩터링 책을 읽다가 버전 관리 시스템을 통한 작업 방식에 대해 고심하여 쓴 부분이 있어서 발췌한다.

깃에 대한 지식이 부족해 이해하기가 매우 어려워 중간중간 여러 블로그를 보면서 이해하려고 했다.

 

흔히 볼 수 있는 팀 단위 작업 방식은 버전 관리 시스템을 사용하여 팀원마다 브랜치를 하나씩 맡아서 작업하다가, 결과물이 어느 정도 쌓이면 마스터 브랜치에 통합해서 다른 팀원과 공유하는 것이다.

그런데 이렇게 하면 어떤 기능 전체를 한 브랜치에만 구현해놓고, 프로덕션 버전으로 릴리스 할 때가 돼서야 마스터에 통합하는 경우가 많다. 

 

이 방식의 장점은 작업이 끝나지 않은 코드가 마스터에 섞이지 않고, 기능이 추가될 때마다 버전을 명확히 나눌 수 있고, 문제가 생기면 이전 상태로 쉽게 되돌릴 수 있다.

 

하지만 단점도 반드시 존재한다. 

 

만약 개인 브랜치로 작업하는 기간이 길어질수록 작업 결과를 마스터로 통합하기가 어려워진다. 즉 충돌이 일어날 가능성이 매우 커진다. 

이 고통을 줄이기 위해 마스터를 개인 브랜치로 수시로 리 베이스 하거나 머지한다.  하지만 여러 기능 브랜치에서 동시에 개발이 진행될 때는 이런 식으로 해결할 수 없다. 

 

저자는 머지와 통합을 명확히 구분한다고 한다. 

 

마스터를 브랜치로 머지하는 작업은 단방향이다. 브랜치만 바뀌고 마스터는 그대로다.

반면 통합은 마스터를 개인 브랜치로 가져와서 (pull) 작업한 결과를 다시 마스터에 올리는 (push) 양방향 처리를 뜻한다.

그래서 마스터와 개인 브랜치 모두 변경된다. 

 

예를 들면 개발자A가 개발한 기능이 생각보다 길어졌다. 그렇다면 개발자 A가 마스터와 통합하기 전까지는 다른 사람은 그 내용을 볼 수 없다. 개발자 A가 통합을 했으면 다른 개발자들은 해당 내용이 포함된 마스터를 pull 하여 자신의 브런치에 머지해야 한다. 만약 개발자 A가 다른 개발자의 영역까지 침범하여 수정했다면 프로그램이 동작하지 않을 것이다. 

이처럼 머지가 복잡해지는 문제는 기능별 브랜치들이 독립적으로 개발되는 기간이 길어질수록 기하급수적으로 늘어난다. 

 

그래서 우리는 매우 짧은 통합 주기를 선호한다.이러한 방식을  지속적 통합(CI), 또는 트렁크 기반 개발(TBD)라고 한다.

CI-CD라는 단어를 들어보았을 것이다. 지속적인 통합과 지속적인 배포, 즉 통합과 배포의 주기를 매우 짧게 설정하는 것이다. 

 

CI에 따르면 모든 팀원이 하루에 최소 한 번은 마스터와 통합한다. 이렇게 하면 다른 브랜치들과의 차이가 크게 벌어지는 브랜치가 없어져서 머지의 복잡도를 낮출 수 있다.

 

다만 CI에는 비용이 든다고 한다. 마스터를 건강하게? 유지하고, 거대한 기능을 잘게 쪼개는 법을 배우고, 각 기능을 끌 수 있는 feature toggle(featrue flag)를 적용하여 완료되지 않은 기능이 시스템 전체를 망치지 않도록 해야 한다.

 

근데 왜 이런 내용이 리팩터링 책안에 있는지 궁금하다. 사실 CI는 리팩터링과 궁합이 매우 좋다고 한다. 

리팩터링을 하다보면 코드 베이스 전반에 걸쳐 자잘하게 수정하는 부분이 많을 때가 있다.

예를 들어서 자주 사용되는 공용 인터페이스의 이름이 변경되는 경우에는 머지 과정에서 의미 충돌이 생기기 쉽다. 

 

내가 리팩터링을 진행하였는데 그 범위가 생각보다 크다고 가정하고 마스터와 통합을 진행했다. 그럼 다른 팀원은 해당 마스터와 개인 브랜치를 합칠 것인데, 그 과정에서 심각한 머지 문제가 발생할 것이다. 

켄트 벡이 CI와 리팩터링을 합쳐서 익스트림 프로그래밍 (XP)를 만든 이유도 바로 두 기법의 궁합이 잘 맞기 때문이다.

(호오)

 

그럼 기능별 브랜치 전략은 안 좋은 것일까? 그렇지 않다 사실 오픈 소스 프로젝트에서 믿을 수 없는 프로그래머로부터 커밋이 들어오기 때문에 기능별 브랜치 방식이 적합할 수도 있다. 

혹은 신입 개발자의 기능을 검토하여 마스터에 머지하는 경우라면 매우 적합할 수 있다고 생각한다. 

 

만약 당신이 풀타임 개발자라면 기능별 브랜치가 가져오는 리팩터링 부담은 매우 클 것이다. 따라서 CI를 완벽히 적용하지는 못하더라도 통합 주기만큼은 최대한 짧게 잡아야 한다.