Git Branch Strategy

다양한 Git Branch 전략에 대하여.

내가 git을 처음 접했을 때는, 생각보다 그리 오래전이 아니였다.
2018년도 즈음 처음 접했었다. 그 전에는 FTP 서비스로만 개발을 해왔었는데,
Git은 실무에 아주 많은 영향을 끼쳤고 그래서 나는 개별적으로 공부했다.
여러 사람들과 협업하는 과정에서 수많은 이슈 충돌이 일어났었다.
그러면서 git만 사용하는것이 아닌, ”git을 어떻게 더 잘 활용할까?” 라는 의문에서 찾아 보니
Git 브랜치 전략 이라는 것이 있었고 현재 내가 머물고있는 상황과, 팀에 잘 맞는 전략이 무엇인지
찾아보게 되었으며, 어떠한 전략들이 있는지에 대해 기록했다.

항목

• Git Branch 란?
• Git Branch 여러 전략
• 내 상황에 가장 잘맞는 Git Branch 전략

Git Branch 란?

Git Branch의 정의는 독립적으로 어떤 작업을 진행하기 위한 개념이다.
협업을 진행할 때 같은 리소스안에서 서로 다른 개발 및 수정 과정이 필요할 때
중복처리가 되버리면, 내가 수정한 개발 과정을 통째로 날릴 수 있기 때문에 독립적인 형태로
브랜치를 만들어 각각의 작업을 이루고 하나로 merge(병합) 한다.
브랜치는 각기 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행 할 수 있다.

Git Branch 여러 전략

Git Branch에는 여러가지 사용방법들이 존재하는데, 대표적으로 3가지로 나뉜다.

1. Git-Flow 전략
2. GitHub-Flow 전략
3. GitLab-Flow 전략

1. Git-Flow 전략

git-flow 전략은, feature develop release hotfix master 5가지의 브랜치를 사용한다.

Git-Flow 전략의 핵심

1. feautre

• feature 브랜치는 기능의 구현을 담당한다. 브랜치명은 컨벤션 기준으로 다를 수 있지만, 기본적으로는 feature/{기능명} 으로 짓는다. 예를 들어 Login 기능을 구현할 때에는 feature/Login 으로 짓는다. 하지만, 현재 우리 팀에서는 Jira를 사용하고 있기 때문에, Jira의 연동을 인해 Jira의 스레드 이슈 번호로 등록하며 사용한다. 실제로는 명확한 기능을 사용 하지는 않지만 만약 그렇게 하면 feature 브랜치와 이슈의 git으로 연동이 가능하기 때문이다. feature 브랜치의 경우, master 나 develop 브랜치에서 생성되며 기능구현과 merge(병합) 이 완료 될때 브랜치를 삭제한다.

2. develop

• develop 브랜치는 개발서버를 담당하는 중심적인 브랜치이다. 하나의 feature 브랜치가 머지될 때 마다 develop 브랜치에 해당 기능이 더 해진다. develop 브랜치는 배포할 수준의 기능을 갖추면, release 브랜치로 병합된다.

3. release

• release 브랜치는 개발된 내용을 배포 준비하기 위한 브랜치이다. 해당 브랜치에서는 충분한 테스트를 통해 버그를 검사하고, 수정해 배포 준비가 완전히 되었다고 판단되면 master 브랜치로 병합한다.

4. hotfix

• hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치이다. release 브랜치를 거쳐 버그 검사를 했지만, 예상치 못한 배포 후에 발견된 버그들에 대해서 수정하는 브랜치이다. hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, release 브랜치와 master 브랜치에 수정사항을 반영한다.

5. master

• master 브랜치는 최종적으로 배포가 되는 가장 중요한 브랜치이다. 실제 운영서버를 뜻하기도 하며, develop 브랜체어서는 개발이 진행되는 와중에도 이전 release 브랜치 내용이 master 브랜치에서는 항상 최신화가 되어있어야 한다.

Git-Flow 전략의 순서

1. feature 브랜치에서 기능개발 완료
2. develop 브랜치로 머지(병합) 후 검증(테스트) 진행
3. release develop 브랜치에서 검증완료된 소스 병합, 이 단계에서 문제 발생 시 해결 후, 다시 develop와 release 단계 반복
4. master 브랜치에 최신의 기능소스를 추가 및 유지
5. 실제로 운영서비스를 할때 발견되는 오류 등은 hotfix 브랜치에서 수정 후 develop 브랜치로 병합 및 기존 단계 시행

Git-Flow 전략의 장,단점

장점

• 브랜치별로 역할군이 정해져 있음.
• 디테일하고 최신화된 버전 정보 제공 가능.

단점

• 여러 브랜치의 역할군을 알아야하며, 혼동이 쉽고 복잡하여 실수가 많을 수 있음.
• release로 인한 많은 동기화 작업 필요.

2. GitHub-Flow 전략

github-flow 전략은, master 1가지의 브랜치를 사용한다.

github-flow 전략은, git-flow 전략의 복잡함 때문에 간단하게 나온 전략이다.

GitHub-Flow 전략의 핵심

1. master

• master 브랜치에서부터 파생 시켜 작업 이후 머지(병합) 한다.

GitHub-Flow 전략의 순서

• 모든 기능개발은, master 브랜치에서 파생 시킨 뒤 작업하고, 다시 master 브랜치로 병합한다.

GitHub-Flow 전략의 장,단점

장점

• 짧은 생산 주기와 빈번한 릴리스로 빠르고 능률적인 분기 전략이다.
• 문제가 발견 될 시, 단순한 구조로 신속한 처리가 가능하다.
• 소규모 팀 또는 웹 애플리케이션, 단일 프로덕션 버전을 유지할때 적합하다.

단점

• 여러 버전의 코드를 처리하는 구조에는 적합하지 않다.
• 개발 분기가 별도로 없기 때문에, 버그에 더 취약하다.
• 하나의 분기에서 작업해야하기 때문에 작업자들 간에 충돌 가능성이 크다.

3. GitLab-Flow 전략

gitlab-flow 전략은, git-flow 와 github-flow의 보완할 점을 분석하여 나온 전략이다.

각각 git-flow 와 github-flow의 장점과 합친 전략이다.

gitlab-flow 전략은, feature master production pre-production 4가지의 브랜치를 사용한다.

GitLab-Flow 전략의 핵심

1. feautre

• 기능 구현은 feature에서 작업하고, master브랜치에서 파생, 머지 되어야 한다.

2. master

• git-flow의 develop브랜치와 동일한 기능을 수행한다. feature브랜치에서 병합된 기능에 대해 테스트, 검증을 진행한다. 검증이 완료되면 production브랜치로 병합한다.

3. production

• git-flow의 master브랜치와 동일한 기능을 수행한다. 검증이 완료된 기능에 대하여 배포를 위한 브랜치이다.

4. pre-production

• master브랜치 와 production브랜치 사이에 pre-production브랜치를 두어 변경사항을 즉시 production브랜치에 배포하지 않고, 테스트 서버로 남겨두거나 시간을 두고 반영하는 브랜치이다.

내 상황에 가장 잘맞는 Git Branch 전략