1. Git Flow

Git-flow는 브랜치를 크게 5가지로 나누어 개발하는 전략입니다.

• 메인 브랜치(Main branch) : 고정
  - 배포 가능한 상태만을 관리하는 브랜치
  
  

• 개발 브랜치(Develop branch) : 고정
  - 다음에 배포할 것을 개발하는 브랜치
  - develop  브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행
  
  

• 피처 브랜치(Feature(or Topic) branch) : 필요할 때 생성/삭제
  - 기능을 개발하는 브랜치
  - 개발 브랜치에서 분기하는 것이 기본 정책
  - 피처 브랜치는 그 기능을 다 완성할 때까지 유지하고, 다 완성되면  develop 브랜치로 merge

  - 피처 브랜치는 보통 개발자 저장소에만 있는 브랜치고 origin에는 push 하지 않는다
  
  

• 릴리스 브랜치(Release branch) : 필요할 때 생성/삭제
  - develop 브랜치에 이번 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성
  - 배포를 위한 최종적인 버그 수정 등의 개발을 수행
  - 배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그를 추가
  - release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해 주어야 함.
    그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행
  
  

• 핫픽스 브랜치(Hotfix branch) : 필요할 때 생성/삭제
  - 배포한 버전에서 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치
  - 버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다
  - 이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해 주어야함

가장 중심이 되는 브랜치는 master와 develop 브랜치이며,  merge된 feature, release, hotfix 브랜치는 삭제하도록 합니다.

 

Git-flow 전략은 주기적으로 배포를 해야하는 프로젝트에는 적합하지만,

브랜치가 많아 복잡하고 어떤 프로젝트에 따라서는 몇몇 브랜치가 애매한 포지션을 가질 수 있습니다.

2. Github Flow
https://build5nines.com/introduction-to-git-version-control-workflow/ 
 - 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용함

 - master 브랜치와 기타 브랜치로 나뉘며, 기능 개발이나 bugfix를 위해서는 아래와 같은 룰을 따름
    1) master 브랜치에서 신규 브랜치 생성
    2) 신규 브랜치에서 기능 구현 및 테스트
    3) 완성되면 pull request
    4) review 및 추가 수정 후 master 브랜치에 merge

 - master 브랜치
    1) 어떤 때든 배포가 가능하며, 실제 프로덕트로 배포되는 브랜치
    2) 따라서 다른 개발 브랜치를 master로 merge하기 전에 충분히 테스트해야 함.
        merge 후 테스트가 아니라 local이나 jenkins등 CI/CD 툴을 이용해 검증 후 merge해야 함
    3) master에 변경사항이 생기면 자동으로 배포되도록 설정 필요함

 - 기타 브랜치
    1) 개발이나 bugfix 목적의 브랜치로, 목적을 명확히 알 수 있도록 이름을 짓는 것이 중요함
    2) 다른 부서나 개발자와의 협업 등을 위해서, 기타 브랜치에는 commit을 자주 remote push해 주는 것이 중요함
        * Commit Message 등도 중요


3. Gitlab Flow
https://about.gitlab.com/blog/2014/09/29/gitlab-flow/
Gitlab Flow는 기본적으로 Github Flow와 동일한데, production 브랜치가 1개 더 추가되있다고 보면 된다.
master 브랜치 자체는 일단 기본적으로 안정적이고 바로 배포 가능한 상태이지만, 실제로 배포가 되지는 않는다.

외부에서 배포 승인이 떨어지면 해당 시점에 master 브랜치에서 production 브랜치로 merge가 이루어지며,
그럼 production 브랜치는 자동으로 배포하게 된다.

즉, master 브랜치의 역할 중 "자동 배포"역할을 production 브랜치로 분리해서 배포 시점을 조절할 수 있도록 개선한 Flow이다.