브랜치 전략

브랜치 전략은 Git 브랜치를 효과적으로 관리하기 위한 하나의 워크플로우이다.

프로젝트를 진행할 때 마다 브랜치를 어떻게 관리할 것인지 규칙을 직접 정해서 사용해도 되지만, 우리 보다 이미 수많은 경험을 거친 고수 개발자들이 시행착오를 거치며 만들어낸 최적의 브랜치 전략을 사용하는 것이 시간 효율면에서는 뛰어날 수 있다.

그렇다면 어떤 브랜치 전략이 있는지 그리고 어떤 장단점이 있는지 알아보도록 하자.

1. Git Flow 브랜치 전략

Git Flow는 브랜치를 크게 Main 브랜치와 Supporting 브랜치라는 상위 브랜치 개념을 사용한다.

Main 브랜치는 master 브랜치와 develop 브랜치를 , Supporting 브랜치는 feature 브랜치, release 브랜치, hotfix 브랜치로 나뉘기 때문에 사실상 5개의 브랜치로 나누어 관리한다고 생각하면 된다.

master 브랜치와, develop 브랜치는 개발 프로세스 동안 항상 유지되는 브랜치이다. Supporting 브랜치는 필요할 때마다 생성되고, 역할을 다하면 삭제되는 제한적인 생명주기를 갖는다.

master 브랜치

master 브랜치는 출시 가능한(production-ready) 프로덕션 코드가 반영되는 브랜치이다. 배포된 각 버전을 Tag를 이용해 표시해둔다.

develop 브랜치

다음 버전 개발을 위한 코드를 반영하는 브랜치이다. 개발이 완료되어 출시 가능한 상태가 되면 master 브랜치로 머지된다.

feature 브랜치

기능을 개발하기 위한 브랜치이다. develop 브랜치에서 생성하고 개발이 완료되고 나면 develop 브랜치로 머지해야 한다.

머지할 때에는 Fast-Forward merge가 아닌, Recursive merge를 사용해야 한다. 그래야 히스토리가 특정 기능 단위로 묶이기 때문에 관리가 용이하다.

release 브랜치

소프트웨어 배포를 준비하기 위한 브랜치이다. develop 브랜치에서 생성하며, 버전 이름 등을 변경하거나 사소한 버그를 수정이 가능하다.

배포 준비가 완료되었다면 master와 develop 브랜치에 둘 다 머지한다. 이때, master와 develop브랜치에는 태그를 이용하여 버전을 표시해야 한다.

hotfix 브랜치

이미 배포된 master 브랜치에서 문제가 발생했다면, hotfix 브랜치를 생성하여 문제를 해결한다. 문제 해결이 완료되면 master와 develop브랜치에 둘다 머지한다.

hotfix 브랜치가 있음으로 develop 브랜치에서는 다른 사람이 하던 작업을 계속할 수 있다.

Git Flow의 단점

위에서 보면 알겠지만, Git Flow는 작업을 매우 세분화해서 여러 가지 브랜치로 분리해 작업한다.

하지만 웹 애플리케이션에서는 저렇게 세분화된 브랜치가 필요하지 않는 경우가 많다.

Git Flow 브랜치 전략을 처음 제안한 개발자는 이런 말을 했다.

"웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다."

대충 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다는 뜻이다.

필자는 아직 초보 개발자라 Git Flow가 웹 애플리케이션에서 적합하지 않은 이유가 크게 와닿지는 않지만, 일단 그렇다고 한다.

그리고 무조건 그렇다는 것도 아닐거라고 생각한다.

2. GitHub Flow 브랜치 전략

결론은 Git Flow는 체계적인만큼 조금 복잡하기도 하고 특정 개발 환경에 따라서는 과한 브랜치 전략이 될 수 있다.

Github Flow는 Git Flow와 다르게 굉장히 간단한 구조를 제공한다.

Github Flow는 이름처럼 Github 환경에서 사용하기 적합한 브랜치 전략이다.

개발자들 뿐만 아니라 깃헙을 사용하는 사람들의 프로젝트에서 모두 유용하게 쓰일 수 있는 간단한 브랜치 전략이라는 뜻인 것 같다.

실제로 깃헙은 site policy, documentation, and roadmap에 대한 레포지토리 관리를 GitHub Flow로 진행하고 있다.

위처럼 release 브랜치가 명확하지 않은 시스템에서 사용하기에 적합하여 release 개념이 없이지고 있는 웹 서비스 개발에도 사용하는 듯 하다.

GitHub Flow의 흐름

1. 어떤 작업을 하기 위해서 브랜치를 새로 만들자.

GitHub Flow는 기본(메인) 브랜치에 영향을 주지 않기 위해서 항상 어떤 작업을 할 때에는 브랜치를 만들어서 작업해야 한다. 브랜치에 대해서는 따로 제약은 없지만 브랜치 이름과 커밋 메시지는 어떤 일을 하는지 명확하게 작성해야 한다.

2. 원격지 브랜치에 수시로 push한다.

원격지에 커밋 이력을 수시로 push해서 다른 디바이스에서 접근 가능하게 하고, 다른 사람들도 자신이 하고 있는 일이 무엇인지 확인할 수 있도록 한다. 이는 백업용도로서도 도움이 된다.

3. Pull Request(PR)를 생성하라.

피드백이나 도움이 필요할 때 자신의 코드를 공유하고, 리뷰를 받을 수 있다. 개발이 완료되어 merge 준비가 되었다면 PR을 통해 master 브랜치로 반영을 요구할 수도 있다.

4. 리뷰를 달아라.

Pull Request에 대해 팀원들은 리뷰를 달아야 한다.

5. 메인 브랜치로 merge하라.

리뷰가 승인되었다면 메인 브랜치로 개발 내용을 merge 해야 한다. 브랜치 방어 설정을 통해 특정 수의 승인이나 특정 팀원으로부터 승인이 떨어졌을 경우에만 merge가 가능하게 할 수 있다.

6. 브랜치를 삭제하라.

Pull Reqeust Merge가 끝났다면 개발이 완료된 브랜치는 제거해야 한다. 이는 개발이 완료되었음을 알리는 동시에 이후 오래된 브랜치에서 작업하게 되는 실수를 방지한다.

GitHub Flow 특징

1. 메인 브랜치는 항상 Stable 해야 한다.

Stable하다는 것은 메인 브랜치의 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다는 뜻이다.

Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야 한다고 한다. (엄격한 테스트를 거쳐야 한다는 뜻이다)

2. 자동화를 권장한다.

자동화를 권장하는 브랜치 전략이기 때문에, GitHub Flow를 사용하면 지속적인 배포가 일어나야 하는 웹 서비스에서 효울적이다.

release의 경우는 크게 크게 가끔씩 한 번 배포하는 개념이기 때문에 자동화가 굳이 필요 없다.

개인적인 생각

위의 흐름을 보면 알겠지만 GitHub Flow 라는게 따로 브랜치 전략으로서 만들어졌다기 보다는 깃헙을 사용하는 가이드 라인이다. 브랜치 전략이라고 설명했지만, 브랜치에 대한 부분만 다루는게 아니고 깃헙의 전반적인 사용 흐름까지 담고 있다.

아마도 깃헙 사이트에서 개발자뿐만 아니라 모두가 적용할 있는 범용적인 프로젝트 관리 가이드 라인으로서 제공한 개념인데, 그것을 그대로 가져온 뒤, 개발 프로젝트에 적용하기에는 부족한 부분을 보완하여 브랜치 전략으로서 사용하고 있는 것이 아닐까 싶다.

실제로 보면 위의 GitHub Flow 특징에서 다룬 내용들은 공식 문서에 따로 담겨 있지 않은 내용들이다.

그래서 일반적으로 GitHub Flow 브랜치 전략이라고 하면 깃헙에서 제공하는 가이드라인 그 자체 보다는 거기에 플러스로 보완되어 설계된 브랜치 전략을 부르는 단어라고 보면 될 것 같다.

또는 둘은 완전히 별개의 개념이고, 공식 문서에서의 GitHub Flow는 단순히 사용 가이드라인 섹션이고, GitHub Flow 브랜치 전략은 브랜치 전략으로서 따로 존재하는 개념이라고 생각도 될 것 같다.

( 물론 개인적인 생각이고 필자는 후자로 생각하는 편이 일반적인 개발자 대화에서는 먹힐 거라고 생각한다. )

3. GitLab Flow 브랜치 전략

GitLab Flow는 Git Flow는 너무 복잡하고 GitHub Flow는 너무 단순하니 그 중간쯤 되는 무언가를 위해 나온 브랜치 전략이다.

GitLab에서는 Git Flow의 경량화된 전략이라고 설명하고 있다.

main 브랜치

GitLab Flow는 Git Flow와 다르게 develop 브랜치를 생성하지 않고 master 브랜치를 사용한다.

master 브랜치의 역할은 Git flow의 develop 브랜치와 동일하다.

feature 브랜치에서 병합된 기능에 대해 테스트를 진행하고 기능에 대한 보장이 되었다면 production 브랜치로 머지한다.

이러한 테스트 과정을 여러 단계로 단계화 하기 위해 원하는 만큼의 pre-production 브랜치를 만들 수 있다.

EX) main → test(pre-production) → acceptance(pre-production) → production(최종)

feature 브랜치

기능 구현은 feature 브랜치를 만들어 진행된다. feature 브랜치는 master 브랜치에서 분기되고 머지된다.

production 브랜치

GitLab Flow의 production 브랜치 역할은 GitLab Flow의 master 브랜치와 같다. 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치이다.

pre-production 브랜치

master 브랜치와 production 브랜치 사이에 pre-production 브랜치를 두어 변경 사항을 바로 production 브랜치와 머지하여 배포하지 않고 테스트 서버에 배포하여 테스트를 진행하거나 시간을 두고 반영할 수 있도록 도와 주는 브랜치이다.

정리

이렇게 여러 가지 브랜치 전략에 대해 공부해 보았는데, 뭔가 확실하게 정리된 느낌이 들지는 않는다.

아무래도 정리만으로는 크게 도움이 되지 않고 여러 전략들을 사용하는 프로젝트를 실무로 겪어봐야 할 것 같다.