branch란?
독립적으로 어떤 작업을 진행하기 위한 개념.
필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다.

git branch 전략이란?
브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow이다.
브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서 각 개발자들이 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다.
즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.

Git branch 전략

1. git flow

• git flow에는 5가지 브랜치가 존재한다.
• 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.

• master: 제품으로 출시될 수 있는 브랜치
• develop: 다음 출시 버전을 개발하는 브랜치
• feature: 기능을 개발하는 브랜치
• release: 이번 출시 버전을 준비하는 브랜치
• hotfix: 출시 버전에서 발생하는 버그를 수정하는 브랜치

위 그림은 git flow 전략을 사용했을 경우의 개발 흐름을 나타낸다.
1. 처음에는 master와 develop 브랜치가 존재한다. develop 브랜치는 master에서부터 시작된 브랜치이며, develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다.
새로운 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 된다.
2. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성하고, QA를 진행하면서 발생한 버그들은 release 브랜치에서 수정된다.
QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 한다.
마지막으로 출시된 master 브랜치에서 버전 태그를 추가한다.
3. hotfix 브랜치의 경우 제품에서 버그가 발생했을 경우 master에서부터 생성되며, 버그에 대한 수정이 완료되면 develop, master 브랜치에 반영해주며 tag를 통해 관련 정보를 기록해둔다. 버그를 고치기 위해 생성된 브랜치이기 때문에 버그를 해결하면 보통 제거하는 일회성 브랜치이다.

2. github flow

• git-flow가 github에서 사용하기에는 복잡하다고 여겨져 나온 브랜치 전략
• 자동화 개념이 들어가 있다는 큰 특징이 존재하며, 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.
• git flow에 비해 흐름과 규칙이 단순하다.
• 기본적으로 master 브랜치에 대한 규칙만 정확하게 정립되어 있다면 나머지 브랜치에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장한다.

1. master 브랜치는 항상 최신 상태이며, stable 상태로 product에 배포되는 브랜치이다.
   새로운 브랜치는 항상 master 브랜치에서 생성되고, git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다. 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 명확하고 자세하게 어떤 일을 하고 있는지에 대해 작성해주어야 한다.

2. 개발을 진행하면서 커밋을 남길 때, 이때도 브랜치와 같이 커밋 메시지에 의존해야 하기 때문에 커밋 메시지를 최대한 상세하게 적어주는 것이 중요하다. git-flow와는 다르게, 원격지 브랜치로 수시로 push하여 다른 사람들이 자신이 하고 있는 일을 확인할 수 있도록 해준다. 이는 하드웨어에 문제가 발생해 작업하던 부분이 사라지더라도 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다.

3. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다. pull request는 코드 리뷰를 도와주는 시스템으로, 이것을 이용해서 자신의 코드를 공유하고 리뷰받는다. merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

4. pull-request가 master 브랜치 쪽에 합쳐진다면 라이브 서버에 배포되는 것과 다름 없으므로 상세한 리뷰와 토의가 이루어져야 하고, 리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다. 배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

5. 라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시하고, 즉시 배포를 진행한다. 대부분의 github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 merge 즉시 배포시킨다.

git flow vs github flow

• 1개월 이상의 기간동안 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등을 수행할 수 있는 여력이 있는 팀이라면 git flow가 적합하다.
• 수시로 release 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 간단한 github-flow가 적합하다.