Git 브랜치 전략, Git-Flow, Github-Flow

Git 브랜치 전략 

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow 이다. 

 

브랜치 생성, 삭제, 병합 등 git 의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다. 

 

즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다 .

 

만약 브랜치 전략이 없다면? 

브랜치 전략이 없을 때 단점은 다음과 같다. 

• 어떤 브랜치가 최신 브랜치지?
• 어떤 브랜치를 끌고와서 개발을 시작해야 하지? 
• 어디에 push 해야하지? 
• 핫픽스를 해야 하는데 어떤 브랜치를 기준으로 수정해야 할까? 
• 배포 버전은 어떤 걸 골라야하지? 

가장 널리 사용되는 브랜치 전략은 다음 2가지이다. 

• git-flow 전략 
• github-flow 전략 

Git-Flow 전략 

기본적인 브랜치의 이름은 다음 5가지로 구분한다. 

• feature > develop > release > hotfix > master 
• 위 순서들은 왼쪽으로 갈수록 포괄적인 의미에 브랜치이며, master 브랜치를 병합할 경우 왼쪽에 있는 hotfix 등 모든 브랜치에 있는 커밋들도 병합하도록 구성하게 된다. 
• 5가지 브랜치는 다음과 같이 분리할 수 있다. 
  • 항시 유지되는 브랜치 : master, develop
  • merge 되면 사라지는 보조 프랜치 : feature, release, hotfix

Git-Flow 브랜치  구조

• master : 운영서버에 배포된 브랜치 
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치 
• feature : 추가 기능 개발 브랜치. develop 브랜치로 merge 된다. 
• release : 다음 버천 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다. 
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치 

메인 브랜치 

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다. 

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며, 

develop 브랜치는 다음에 배포할 것을 개발하는 브랜치이다. 

즉, develop 브랜치는 통합 브랜치 역할을 하며, 평소에는 이 브랜치 기반으로 개발을 진행한다. 

보조 브랜치 

보조 브랜치는 feature 브랜치 or topic 브랜치 라고 부른다. 

• 브랜치가 뻗어나오는 곳 : feature
• 뻗어나갔던 브랜치가 다시 merge 하는 곳 : develop
• 새로운 기능을 추가할 때 주로 사용하는 브랜치이다. 

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 

보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보전하는 역할을 한다. 

즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하는 버리는 방향을 취한다. 

보조 브랜치는 보통 개발자 저장소에만 있는 브랜치이고, origin 에는 push 하지 않는다.

릴리즈 브랜치  

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다. 

• 브랜치가 뻗어나오는 곳 : develop
• 뻗어나갔던 브랜치가 다시 merge 하는 곳 : develop, master
• 새로운 제품을 배포하고자 할 때 사용하는 브랜치이다.

핫픽스 브랜치 

핫픽스 브랜치는 운영배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다. 

• 브랜치가 뻗어나오는 곳 : master
• 뻗어나갔던 브랜치가 다시 merge 하는 곳 : develop, master
• 제품에서 버그가 발생했을 때, 처리를 위해 이 브랜치로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후 develop, master 에 곧장 반영해준다. 

Git-Flow 흐름 

신규 기능 개발 

1. 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성한다. 
2. feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge 한다. 

운영서버 배포 

1. feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA 를 위해 release 브랜치를 생성한다. 
2. release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행한다. 
3. QA 와 테스트 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge 하며, 
4. 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우, 동기화를 위해 develop 브랜치 쪽에서 merge 를 진행한다.

배포 후 관리 

1. 만일 운영배포 된 서버에서 버그가 발생한다면, hotfix 브랜치를 생성해 버그 픽스를 진행한다. 
2. 그리고 종료된 버그 픽스를 master, develop 양쪽에 merge 하여 동기화 시킨다. 

Github-Flow 전략

• Git Flow 가 좋은 방식이지만 Github 에 적용하기에는 복잡하다는 생각에 만든어진 새로운 Git 관리 방식이다.
• 자동화 개념이 들어가 있다는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.
• Git Flow 에 비해서 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.
• 기본적으로 master 브랜치에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장한다. 

Github-Flow 흐름 

브랜치 생성 

Github-Flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다. 

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다. 

• master 브랜치는 항상 최신 상태이며, 운영서버에 배포되는 브랜치이다. 이 브랜치에 대해서는 엄격한 규칙이 적용되어야 한다. 
• 새로운 브랜치는 항상 master 브랜치에서 만든다. 
• Git-Flow 와는 다르게 feature 브랜치나, develop 브랜치가 존재하지 않는다. 
• 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고있는지 작성해주는 것이 중요하다. 

개발 & 커밋 & 푸시 

개발을 진행하면서 커밋을 남긴다. 

이때도 브랜치와 같이 커밋 메시지에 의존해야 하기 때문에, 커밋 메시지를 상세하게 적어주는 것이 중요하다. 

• 커밋메시지를 명확하게 작성하자 
• 원격지 브랜치로 수시로 push 하자 
• Git-Flow 와 상반된 방식 
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다. 

PR(Pull Request) 생성 

피드백이나 도움이 필요할 때, merge 준비가 완료되었을 때는 pull request 를 생성한다. 

• pull request 코드 리뷰를 도와주는 시스템 
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받는다. 
• merge 준비가 완료되었다면 master 브랜치로 merge 를 요구한다. 

리뷰 & 토의 

PR 이 master 브랜치에 합쳐진다면 곧장 운영 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다. 

테스트

리뷰와 토의가 끝났다면 해당 내용을 운영 서버(혹은 테스트 서버) 에 배포해본다. 

배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다. 

 

최종 Merge 

 

운영 서버(혹은 테스트 서버) 에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 push 하고, 즉시 배포를 진행한다. 

대부분의 Github-Flow 에서는 master 브랜치를 최신 브랜치라고 가정하기 때문에, 배포 자동화 도구를 이용해서 Merge 후 즉시 배포시킨다. 

Git-Flow vs Github-Flow 

그렇다면 혼자서 개발하고 멘토님에게 리뷰를 받는 현재 상황에서 어떤 방법을 선택해야 할까?
당연히 Github-Flow 이다!

위 설명을 보아도 알겠지만, Git-Flow 는 브랜치가 많아 복잡도가 높고, 빠른 배포 주기(멘토님께서 이슈 1개당 하루를 넘지 않도록 하자고 말씀하셨다) 를 요구하는 프로젝트에는 부적합하다.

혼자 진행하는 프로젝트에서 불필요한 복잡도는 최고의 적! 선택권은 없다! 무조건 Github-Flow 이다. 

아마 규모가 큰 이슈를 관리하거나 긴 개발 주기를 가진 프로젝트에서는 Git-Flow 가 좋은 방안이 될 수 있겠다고 생각해본다.