https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Gitflow Workflow | Atlassian Git Tutorial
A deep dive into the Gitflow Workflow. Learn if this Git workflow is right for you and your team with this comprehensive tutorial.
www.atlassian.com
1. branch 종류 설명
여기서 말한 브랜치들은 특정 브랜치 하나를 의미하는게 아닌 브랜치들의 라이프 사이클을 의미합니다.
master브랜치와, develop브랜치는 하나로 고정이지만 release, hotfix, feature 브랜치들은 때에따라 생성과 소멸을 하게 됩니다
1.1 master branch
마스터 브랜치 이며 실행 가능한 제품 상태의 버전, 최종 release 버전만 이 브랜치로 올립니다.
1.2 hotfix branches
마스터 브랜치로 업로드 되기 전까지 미처 발견되지 못한, 사용상에 생긴 버그들을 급하게 픽스해야할때 사용할 브랜치 입니다.
1.3 develop branch
개발 메인 브랜치 이며, 항상 사용하게될 브랜치 입니다. 이 개발 브랜치에서 특정 기능을 개발해야한다면 feature branch를 만들어 해당 기능을 만든 다음 develop branch로 pull request를 넣어 merge합니다.
develop branch에서 배포 가능한 수준까지 개발이 된다면 release branch로 업로드하여 최종 release까지 점검을 진행합니다.
1.4 feature branches
기능을 개발하는 브랜치로, develop 브랜치에서 특정 기능을 개발해야 할때 이 브랜치를 만들어 기능을 개발 후 develop branch로 pull request를 올립니다.
1.5 release branches
배포를 준비하는 브랜치로 develop 브랜치에서 개발이 완료되면 이 브랜치로 옮겨, 배포를 위한 준비를 합니다. 만약 추가 개발이 필요하다면 이 브랜치에서 다시 develop 브랜치로 옮겨 개발 후 다시 release branch로 옮깁니다.
2. 시나리오
2.1 개발 시작
개발 시작은 master 브랜치에서 develop브랜치를 만들며 시작합니다. 개발 시작과 동시에 develop 브랜치 에서 프로젝트를 만들어 개발을 진행합니다.

master 브랜치에서 develop 브랜치 생성

2.2 기능 개발
특정 기능을 개발할때는 develop 브랜치에서 feature 브랜치를 만들어서 개발합니다.
ex) 운동 기능을 만든다면 develop 브랜치에서 feature/exercise 브랜치를 만들어 해당 브랜치에서 개발이 완료된 후 develop 브랜치로 머지합니다.
develop 브랜치에서 feature/exercise 브랜치 생성

2.3 feature/exercise 브랜치에서 개발 종료

2.4 develop 브랜치에서 feature/exercise브랜치를 머지

2.5 배포 준비
develop 브랜치에서 기능 개발들이 완료되고 배포를 한다면 develop 브랜치에서 release 브랜치를 만듭니다.
ex) 1.0.4 release를 하기 위한다면 develop브랜치에서 release/1.0.4_beta 이런식으로 브랜치를 하나 만듭니다.
이 release브랜치에서는 버그 수정 수준의 작업만 진행하게 됩니다.
2.6 develop브랜치에서 release 브랜치 생성

2.7 release 브랜치에서 버그 픽스
release하려던중 버그가 나타나 버그를 픽스함.

2.8 배포
release 브랜치에서 검토가 끝난 브랜치는 master 브랜치와 머지하게 됩니다.
2.9 터미널에서 확인한 전체 시나리오
- master -> develop 생성
- develop -> feature 생성
- feature -> develop 머지
- develop -> release 생성
- release -> 버그 픽스
- release -> master 머지

2.10 핫픽스
release 브랜치에서 미처 찾지 못한 버그들을 급하게 수정할때는 master 브랜치에서 hotfix 브랜치를 만들어 버그 수정 후 다시 master 브랜치와 머지합니다.
핫픽스가 생겨 마스터에서 브랜치 생성후 핫픽스

핫픽스 이후 마스터와 머지

소스트리로 본 전체 진행 그래프

프로젝트를 만들어 exercise 기능을 만들어 v1.0.0 배포
food 기능을 만들어 v1.0.1을 배포하기까지의 전체 과정이다.
fastfoward, non-fastfoward
remote 서버의 커밋과 머지시 두가지 방법이 존재한다.
- fastfoward
- non-fastfoward
master와 한단계 앞에있는 develop 브랜치
위 상황은 master 브랜치에서 생성된 develop 브랜치에서의 작업이 완료되어
master가 develop과 머지할려는 상황이다.
이 상황에서
git merge develop 명령으로 단순 머지를 하게되면 fast-foward로 머지하게 된다.
git merge develop 결과

fast-foward는 내 앞에 있는 커밋을 따라잡는 형식의 머지다.
이때 —-no-ff 옵션을 통해 fast-foward가 아닌 머지를 하게 되면, 마스터는 develop을 따라잡는것이 아닌, develop과 머지한 새로운 커밋을 만들어 머지하게 된다.
git merge develop –no-ff 결과

fast-foward를 사용하지 않고 머지를 하게 되면 develop에서 개발한 기록이 따로 남게 되어 마스터와 구분할 수 있게 된다.