프로젝트를 시작하며(branch 전략)

앞서 merge 전략에 이어 내가 앞으로 할 프로젝트의 branch 전략과 왜 이러한 branch 전략을 선택했는지에 대해 정리를 해보겠다.

 

우리는 개발을 진행하면서 우리가 구현한 소스코드를 git이라는 버전 관리 시스템을 통해 관리한다. git을 사용함으로써 우리는 시시각각 코드를 전송할 수 있으며, commit 내역을 통해 어떤 작업이 이루어졌는지 확인할 수 있다. 협업을 할때에도 git을 이용해 각각의 환경의 branch에서 작업을 하고 메인 저장소에 merge를 하며 협업을 할 수 있는데 우리는 어떠한 방식으로 branch를 나누고 개발할수 있을까에 대해서 말해보려고 한다. 

 

대표적인 전략인 git flow, git lab flow, github flow에 대해서 설명하고자 한다.

 

git flow

git flow는 feature, develop, release, hotfix, master 5가지의 브랜치를 갖는다.
아래 사진은 git flow의 브랜치 전략을 가장 잘 드러내주는 그림이다.

각각의 브랜치에 대해서 간략하게 알아보자.

1. feature
   feature 브랜치는 기능의 구현을 담당한다.
   브랜치명은 팀마다 컨벤션을 가지고 지을 수 있지만 feature/{구현기능명}과 같은 명칭을 준수하는 것이 일반적이다.
   예를 들어, feature/login은 login 기능을 구현하는 브랜치임을 알 수 있다.
   feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지된다.
   머지된 후에는 해당 브랜치가 삭제된다.
2. develop
   develop 브랜치는 이름과 같이 개발이 진행되는 브랜치이다.
   develop 브랜치에서 feature 브랜치가 파생되어 feature 브랜치에서 작업 한 후 devlop 브랜치로 머지해 나간다.
   develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 머지된다.
3. release
   release 브랜치는 배포를 하기 전 검증을 하는 브랜치 이다.
   브랜치명은 release-1과 같은 방식으로 첫번째 릴리즈, 두번째 릴리즈 등을 지정하는 것이 보편적이다. release 브랜치는 develop 브랜치에서 파생되며, release 브랜치에서 충분한 검증을 통해 배포할 준비가 됐다고 판단이 되면 master 브랜치에 머지한다.
4. hotfix
   hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치이다.
   브랜치명은 hotfix-1로 지정된다. hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, release 브랜치와 master 브랜치에 수정 사항을 반영한다.
5. master
   master 브랜치는 최종적으로 배포되는 가장 중심의 브랜치이다.

Git flow 브랜치 전략은 여러 브랜치들이 존재하고 각 브랜치마다 상황이 명확하게 분류되어 있지만, 오히려 이렇게 많은 브랜치가 흐름을 더욱 복잡하게 만들기도 한다.

게다가 release 브랜치와 master 브랜치의 경계는 모호해 보이기도 한다.
하지만 프로젝트의 규모가 커지면 커질수록 소스코드를 관리하기에 용이하다는 장점이 있다.

 

Github Flow

github flow는 git flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략이다.
github flow는 master 브랜치 하나만을 가지고 진행하는 방식으로, 기능구현이나 버그가 생기거나 배포를 하기 전이나 모든 작업 사항에 대해서 master 브랜치에다가 merge 하여 진행한다.

아래 흐름은 github flow의 흐름을 보여주는 그림이다.

 

github flow에 과정에 대해서 알아보자.

1. master 브랜치에서 개발이 시작된다.
2. 기능 구현을 해야하거나 버그가 발생시 issue에 작성한다.
3. issue에 작성한 내용을 해결하기 위해 master 브랜치에서 파생되는 브랜치를 하나 만든다.
4. 해당 브랜치에서 작업을 하면서 commit을 작성한다.
5. 작업이 완료 되면 pr을 올린다.
6. 올린 pr에 대해서 검증하고 검증이 끝나면 master 브랜치에 합쳐진다.

github flow는 시시각각 master에 머지될 때마다 배포가 이루어지는 것이 좋다.

또한 브랜치 전략이 단순하여 master에서 branch를 파서 작업하고 pr올리고 머지하고의 반복이다.

하지만 올린 pr에 대해서 검증이 확실하게 이루어지지 않으면 배포된 내용이 버그가 발생할 수 있다.

 

GitLab Flow

gitlab flow는 복잡하지 않고 효율을 높이고자 생겨난 브랜치 전략으로 master, feature, production 브랜치가 존재한다.
github flow와 git flow의 방식을 섞은 방법으로 다음의 그림을 통해 흐름을 알 수 있다.

 

각 브랜치에 대해서 알아보자.

1. feature
   모든 기능 구현은 feature 브랜치에서 진행된다.
   이 feature 브랜치는 master 브랜치에서 나와 master 브랜치로 머지된다.
   기능 구현이 완료되면 merge request를 보낸다.
   merge request에서 팀원 간의 협의가 완료되면 master 브랜치로 머지한다.
2. master
   gitlab flow의 master 브랜치는 git flow의 develop 브랜치, release 브랜치와 역할이 같다.
   production 브랜치에 머지되기 전에 테스트가 이루어 지기도 하며 개발이 이루어지는 브랜치 이기도 하다.
3. production
   git flow의 master 브랜치와 같다.
   master 브랜치에서 작업이 끝나고 테스트도 끝나면 production 브랜치에 병합이 된다.
   하지만 여기서 견고한 test를 거치고 싶은 경우 pre-production 브랜치를 생성해 production에 병합하기 전에 test server에 배포해 확인할 수도 있다.

gitlab flow는 git flow처럼 복잡하지 않으면서, github flow처럼 너무 단순하지 않아 비교적 적용이 쉬우면서도 원활한 운영이 가능하다.

 

앞으로 내가 진행할 프로젝트는 git flow전략을 선택했다. 규모가 큰 프로젝트가 아니지만 체계적인 branch 구성을 갖고 있는 오히려 내가 하는 프로젝트에서는 과할수도 있는 전략을 선택한 이유는 제일 복잡한 branch 전략을 경험해보고 싶어서이다. 앞으로 개발을 하다보면 큰 규모의 프로젝트에 참여하게 될 수도 있고, 그때의 회사에 맞는 전략이 git flow 전략일수도 있다. 또한 작은 규모의 프로젝트지만 가장 체계적인 브랜치 전략을 이용해 협업을 경험해보고 싶었기에 git flow 전략을 선택했다.