Git branch 전략

Git을 더 잘쓰기 위한 방법

Git flow, GitHub flow, GitLab flow 모두 Git을 더 잘 써먹기 위한 방법들을 이야기한다. 어떻게 하면 대규모 프로젝트들을 더 깔끔하게 관리할 수 있을지를 고민하다 탄생한 것들이다. 특별한 기술이라기 보다도 Git을 관리하기 위한 전략이라고 표현하는게 맞는 표현이다.

Git flow

Git flow 방식은 Vincent Driessen(A successful Git branching model)가 제안한 방식으로 아래 그림과 같이 이루어지는 방식이다. 그림만 이해해도 Git flow에 대한 이해가 다 됐다고 봐도 된다.

그림의 각 브랜치 마다의 역할을 살펴보자

• master : 배포되었거나 지금 당장 배포를 해도 문제없는 소스가 저장된 브랜치
• develop : 다음 배포를 위해 개발을 진행하는 브랜치

master 브랜치와 develop 브랜치는 항상 remote repository에 유지되는 브랜치이다.

master 브랜치는 보통 배포할 때마다 태그를 달아줘서 관리를 한다. develop 브랜치는 개발자들이 각각 자신의 로컬에 브랜치를 따로 생성해서 개발을 진행한 후 해당 개발이 완료가 되면 develop 브랜치에 push 혹은 PullRequest 요청을 해서 merge 하는 루틴으로 개발이 진행된다.

• feature branch : 기능 단위 개발이 진행되는 브랜치
• hotfixs branch : 배포했던 버전에 문제가 생겨서 긴급한 수정이 필요할 떄 그런 개발이 진행되는 브랜치
• release branch : 내부적으로 어느정도 개발이 되었다고 판단되어 배포할 준비가 된 소스가 저장되는 브랜치

Git flow가 대규모 프로젝트에서는 적합할지 모르지만 대다수의 프로젝트에서는 굳이 필요없는 절차까지 준수하도록 해서 생산성을 떨어뜨린다는 의견이 나오게 되었고 그렇게 탄생한 것이 GitHub flow와 GitLab flow다

GitHub flow

master 브랜치는 항상 최신의 상태를 유지하며 stable하다. 이는 항상 배포가 가능하다는 의미이다. GitHub flow에서는 feature나 develop 브랜치 같은 것이 존재하지 않는다. 만약 작업을 위해 브랜치를 따야한다면 작업하는게 무엇인지 명확히 알 수 있도록 브랜치 명을 작성한다. CI가 필수적이며, 배포를 자동으로 진행할 수 있다. GitHub flow에서는 PullRequest 기능을 권장한다. 이를 통해 코드 리뷰를 하기 위해서 이다. Git flow에 비해 간단한 구조로 되어있어서 비교적 신속하게 배포를 수행할 수 있다.

GitLab flow

production 브랜치는 Git flow에서의 master 브랜치와 같은 역할을 한다. GitLab flow에서의 master 브랜치는 production 브랜치로 병합한다. 이를 통해 production 브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신 버전 상태를 유지해야할 필요가 없게 한다.

Git flow와 GitHub flow의 각각의 장점을 절충한 것 같은 느낌이 든다.

결론

Git 브랜치 전략의 선택은 프로젝트의 규모, 복잡성 및 요구사항에 맞아야 한다고 생각한다. 안정성과 구조화된 릴리스가 중요한 대규모 복잡한 프로젝트에는 Git flow가 적합할 것이다. 단순성과 속도를 우선시하는 팀, 특히 지속적 배포가 있는 프로젝트에는 GitHub flow가 GitLab flow는 구조와 유연성 사이의 균형이 필요한 프로젝트에 맞을 것이다. 어떤 브랜치 전략이 무조건적으로 좋다고는 할 수 없을 것이다. 프로젝트의 규모, 팀의 상황 등을 고려해 적절히 브랜치 전략을 선택해야 될 것이다.