1. 탐구

브랜치 전략

1. Git Flow

1. main : 출시 가능한 프로덕션 코드를 모아놓은 브랜치
2. develop : 다음 버전 개발을 위한 코드를 모아놓은 브랜치
   • 개발이 완료되면 main으로 머지
3. supporting : 그 역할이 끝나면 삭제한다.
   1. release : SW배포를 준비하기 위한 브랜치
      • develop에서 분기 → 버전 이름 등의 데이터를 수정하거나 배포 전 사소한 버그 수정을 위해 사용
   2. hotfix : 이미 배포된 버전에 문제가 발생하면 이 브랜치에서 문제 해결
      • main에서 분기 > 문제가 해결되면 main과 develop에 머지
   3. feature : 하나의 기능을 개발하기 위한 브랜치
      • fast-forward가 아닌, merge commit을 생성해 머지 → 히스토리가 특정 기능 단위로 묶인다.

2. github flow

: git flow에 비해 간단한 구조

• master가 그 역할만 유지한다면, 나머지 브랜치엔 관여하지 않는다.

1. main : 출시 가능한 프로덕션 코드를 모아놓은 브랜치
2. topic : git flow의 feature 브랜치와 동일한 역할

3. gitlab flow

: github flow가 너무 간단해, 규모가 큰 서비스에는 부적합 → 단순함을 이용하면서 체계를 갖추기 위해 등장

머지 전략

Merge

: 커밋 이력이 모두 남는다.

1. fast-forward merge : 머지하면, 머지한 브랜치의 작업사항을 모두 연장선으로 나열된다.

   

   $ git checkout master
   $ git merge develop
   

   • 변경사항을 그대로 main브랜치로 가져온다.

2. recursive merge : 머지 커밋을 하나 생성하며, 하나의 브랜치로 합쳐진다.

   

   • 가장 일반적으로 많이 사용
   • -—n-ff옵션을 주면 강제로 merge 커밋을 생성하게 할 수 있다.