Flow Branch 전략

Git에는 프로젝트의 효율적인 협업을 위한 기능적 시스템으로 branch 라는게 있다. 하지만 이러한 브랜치들이 아무 규칙성 없이 마구잡이로 생긴다면 굉장히 혼란스러워질 수 있다. 특히 프로젝트가 커지고 작업 인원이 늘어날수록 이러한 위험성은 더 커지게 된다.

따라서 어떻게 브랜치를 만들고, 어떤 방식으로 프로젝트가 분할되어 진행될 것인지의 전략을 짜야하는데, 이 경우 가장 보편적으로 사용되는 것이 Vincent Driessen이 제시한 Flow Branch 전략이다.
위 사진을 보다시피, flow branch 전략에서는 크게 브랜치를 5종류로 나눈다.

• main : 직접 사용되기 위해 배포되는 프로젝트가 존재하는 메인 브랜치이다.
• develop : 다음 출시될 버전의 개발을 위한 작업이 이루어지는 브랜치이다. 보통 개발이 완료되면 main으로 merge 되거나 rebase 된다.
• feature : 새로운 기능의 개발을 위해 develop 로 부터 갈라져나온 브랜치로, 이 역시 개발이 완료되면 develop 로 merge 되거나 rebase 된다.
• release : 새로운 버전의 배포 이전에 사소한 버그나 이슈 등을 해결하기 위한 브랜치이다. 해결이 완료되면 develop 와 main 으로 merge 되거나 rebase 된다.
• hotfix : 프로젝트상 긴급하게 해결해야 할 이슈가 생기는 경우가 있어, 빠르게 생성되고 빠르게 사라지는 브랜치이다. 문제의 해결이 완료되면 develop 와 main 으로 합쳐진다.

위의 브랜치들을 주축으로, 더 효율적이고 빠른 협업이 이루어질 수 있다. 특히 규모가 매우 큰 프로젝트의 경우, 규칙이 엄격한 특성상 통제가 더 수월할 수 있다.

하지만 이는 명시적으로 버전관리가 필요한 앱 어플리케이션과 같은 경우가 아니라면 적합하지 않을 수 있다. 이를테면 늘 최신의 단일버전만이 지속적으로 제공되는 웹 어플리케이션 같은 경우, 여러 버전을 병렬적으로 지원할 필요가 없기 때문에 위의 Flow Branch 는 너무 복잡하고, 관리도 어려운데다, 여러 필요없는 브랜치들이 많다. 잦은 배포가 이루어지는 웹 어플리케이션 특성상 절차가 너무 복잡하다고 느껴질 수도 있다. 따라서 이를 해결하기 위해 새롭게 제안된 것이 Github Branch 전략이다.

Github Branch 전략

github 브랜치 전략은 위의 주 브랜치가 5개나 되었던 flow 브랜치 전략과 다르게 2가지의 브랜치만을 가져 구조가 매우 단순하다.
먼저 Main 브랜치는 flow 브랜치 전략과 크게 다르지 않지만, 언제나 배포가 가능한, 늘 최신의 상태를 유지해야 한다는 엄격한 규칙이 있다. 그도 그럴것이, 사용자에게 지속적으로 최신 상태의 서비스를 제공하는 브랜치이기 때문에다. 이 브랜치에 최신 버전을 개발하기 위한 여러 브랜치는 별다른 규칙 없이 필요에 따라 생기고 merge 된다. 그리고 이러한 브랜치들의 이름은 생성목적을 명확히 하는 이름으로 만들어진다. 하지만 위의 엄격한 main 브랜치의 규칙에 따라, 개발을 위한 브랜치가 main 브랜치에 merge 되기 전에는 Pull Request 를 통해 검증을 거친다. 이 이후에도 main 브랜치와의 여러 테스트를 거친 뒤 병합이 이루어진다.

위의 전략은 버전 관리가 필요없는 웹 어플리케이션과 같은 프로젝트에 적합하고, 간단하기 때문에 비교적 규모가 작은 인원의 프로젝트가 사용하기에 좋은 전략이다. 또, 배포까지의 단계가 적어 잦은 배포가 이루어지는 프로젝트의 경우 유용하다. 하지만 역시 규모가 크거나, 버전 관리가 필요한 프로젝트의 경우에는 적합하지 않을 수 있다.

정리

위 두 전략 모두, 저마다의 장점과 단점을 가지고 있기 때문에 어느 것이 정답이라고 할 수는 없다. 또 각자 팀의 성향에 따라 위의 방식이 아닌 다른 더 적합한 방식이 존재할 수도 있다. 따라서 팀의 프로젝트의 목적에 맞게, 또는 각자의 성향에 맞게 지금껏 소개한 전략들을 참고하여 좋은 프로젝트 전략을 수립하는 것이 정답이라고 할 수 있겠다.