[Git] Git Branch 전략

0. 개요

협업을 할 때 원활한 프로젝트 관리를 위해 git branch 전략을 사용한다. 이를 통해 버전 관리, 충돌 관리, 개발성 향상의 이점을 얻을 수 있다.
대표적으로 git flow, git hub, git lab 전략이 있고 이를 알아보자.

1. Git-Flow 전략

git flow는 master, develop, feature, release, hotfix 5가지의 브랜치를 갖는다.
master와 dev 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치이다. 그 외의 브랜치는 필요할 때마다 생성되고, 역할을 다하면 삭제된다.

1. feature
   feature 브랜치는 기능의 구현을 담당한다.
   feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지되고 삭제된다.
   브랜치명은 일반적으로 feature/name을 사용한다.

2. develop
   develop 브랜치는 개발을 진행하는 브랜치이다.
   하나의 feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능이 더해지며 살을 붙여간다.
   develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 머지된다.

3. release
   release 브랜치는 배포하기 위해 준비하는 브랜치이다.
   충분한 테스트를 통해 버그를 검사하고 수정해 배포할 준비가 되었다고 판단되면 master로 머지해 배포한다.
   release 브랜치는 develop 브랜치에서 생성되며 버그 수정 내용을 develop 브랜치에도 반영하고, 최종적으로 master 브랜치에 머지한다.
   브랜치명은 일반적으로 release/v1.1과 같이 버전을 명시한다.

4. hotfix
   hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치이다.
   예상치 못하게 배포 후에 발견된 버그들에 대해서 수정한다. hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, release 브랜치와 master 브랜치에 수정 사항을 반영한다.
   브랜치명은 일반적으로 hotfix/v1.0.1로 지정된다.

5. master
   master 브랜치는 최종적으로 배포되는 가장 중심의 브랜치이다.
   develop 브랜치에서는 개발이 진행되는 와중에도 이전 release 브랜치 내용이 master에 있어 배포되어 있다.

• 장점
  • 병렬적으로 업무를 원활하게 할 수 있다.
• 단점
  • 많은 브랜치가 흐름을 복잡하게 만들 수 있다.

2. GitHub-Flow 전략

github flow는 git flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략이다. master 브랜치 하나만을 가지고 진행하는 방식이다.
master 브랜치는 어떤 기능이 구현/수정되든 모두 master에 머지되어 항상 최신 상태를 유지한다.

1. master 브랜치에서 개발이 시작된다.

2. 기능 구현이나 버그가 발생하면 issue를 작성한다.

3. 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature/name 브랜치에서 개발을 하고 commit log를 작성한다.

4. push를 하면 pull request를 날릴 수 있다.

5. pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정이 진행된다. release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 한다.

6. 모든 리뷰가 이루어지면, merge하기 전에 배포를 통해 최종 테스트를 진행한다.

7. 테스트까지 진행되면 master 브랜치에 머지한다.

3. GitLab-Flow 전략

gitlab flow는 복잡하지 않고 효율을 높이고자 생겨난 브랜치 전략으로 master, feature, production 브랜치가 존재한다.

1. feature
   feature 브랜치는 기능의 구현을 담당한다.
   이 feature 브랜치는 master 브랜치에서 나와 master 브랜치로 머지된다. 기능 구현이 완료되면 merge request를 보낸다.

2. master
   merge request에서 팀원 간의 협의가 완료되면 master 브랜치로 머지한다. git flow의 develop 브랜치와 같다.
   master 브랜치는 feature 브랜치에서 병합된 기능에 대해 test 한다.
   전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면 production 브랜치로 머지한다.

3. production
   production 브랜치는 배포 브랜치이다. git flow의 master 브랜치와 같다.
   안정된 소스코드가 되었을 때 production 브랜치에 병합해 배포하도록 한다.
   하지만 여기서 견고한 test를 거치고 싶은 경우 pre-production 브랜치를 생성해 production에 병합하기 전에 test server에 배포해 확인할 수도 있다.

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

gitlab의 CEO는 최대한의 효울을 위해 지켜야 할 11가지 규칙에 대해 서술해두었다.
이 11가지 규칙에 대해서 이해하고 적용한다면 최상의 gitlab flow 전략을 가져갈 수 있을 것이다.

Reference

https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/