참고 블로그

Git Branch 사용하기

• Git Workflow에서는 항상 유지되는 메인브랜치와
  일정 기간만 유지되는 보조 브랜치를 포함해 총 5가지 브랜치를 사용한다.
• 메인 브랜치 : main, develop
  보조 브랜치 : feature, release, hotfix

1. Main Branch

• 제품으로 출시될 수 있는 브랜치.
  배포(Release) 이력을 관리하기 위해 사용한다.
  배포 가능한 상태만을 관리.

2. Develop Branch

• 다음 출시 버전을 개발하는 브랜치
  기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
  모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 'master'브랜치에 병합(merge)한다.
• 평소에는 이 브랜치를 기반으로 개발을 진행.

3. Feature Branch

• 기능을 개발하는 브랜치
  feature 브랜치는 새 기능 개발, 버그 수정이 필요할 때마다 develop브랜치로 분기한다.
  feature 브랜치의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다.
  개발이 완료되면 develop 브랜치로 병합하여 다른 사람과 공유한다.

1. develop 브랜치에서 새로운 기능에 대한 feature 브랜치 분기.
2. 새로운 기능에 대한 작업 수행.
3. 작업이 끝나면 develop 브랜치로 병합
4. 더 필요치 않은 feature 브랜치는 삭제.
5. 새로운 기능에 대한 feature 브랜치를 중앙 원격 저장소에 올림.

// 주의점. main브랜치에서 분기하는 브랜치가 아니라 develop브랜치에서 분기해야한다.
$ git checkout -b feature/~ develop
// ~~기능 개발~~
$ git checkout develop            // 기능 개발 후 develop 브랜치로 돌아감. 
$ git merge --no-ff feature/~     // --no-ff merge는 아래 설명
$ git branch -d feature/~         // feature/~ 브랜치 삭제
$ git push origin develop

• --no-ff
  • 새로운 커밋 객체를 만들어 develop 브랜치에 merge 시킴.
  • 이것은 feature 브랜치에 존재하는 커밋이력을 모두 합쳐 하나의 새로운 커밋 객체를 만들어 develop 브랜치로 병합하는 것.
• feature 브랜치 이름 정하기
  • main, develop, release, hotfit 제외
  • 일반적으로 feature/기능요약 형식. EX)feature/login
    ff 와 no-ff

4. Release Branch

• 이번 출시 버전을 준비하는 브랜치
  배포를 위한 전용 브랜치를 개발함으로써 팀1이 해당 배포를 준비하는 동안 팀2는 다음 배포를 위한 기능 개발을 계속 할 수 있다.
  딱딱 끊어지는 개발 단계를 정의하기 좋음.

1. develop 브랜치에서 배포할 수 있는 수준의 기능이 모이면 혹은 정해진 배포 일정이 되면 release 브랜치를 분기한다.
   • release 브랜치를 만드는 순간부터 배포 사이클 시작
   • 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업 수행.
   • 직접적으로 관련된 작업을 제외하면, release 브랜치에 새로운 기능을 추가로 병합하지 않음.
2. release 브랜치가 배포 가능 상태가 되면(배포 준비 완료)
   • 배포 가능한 상태 : 새로운 기능을 포함, 모든 기능이 정상적으로 동작하는 상태
     1) main 브랜치에 병합. (병합한 커밋에 Release 버전 태그 부여!)
     2) 배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 develop 브랜치에도 병합

다음 배포를 위한 개발 작업은 develop브랜치에서 계속 진행한다.

// 주의점. main브랜치에서 분기하는 브랜치가 아니라 develop브랜치에서 분기해야한다.
$ git checkout -b release-x.x develop
/ ~ 배포 사이클 ~ /
$ git checkout main               // 배포 준비가 완료되면 main 브랜치로 이동
$ git merge --no-ff release-x.x   // 브랜치 병합
$ git tag -a 1.2                  // 버전태그 부여

// 브랜치 변경사항을 develop에도 적용
$ git checkout develop            // develop 브랜치로 이동 
$ git merge --no-ff release-x.x   // 병합
$ git branch -d release-1.2       // release 브랜치 삭제 

• release 브랜치 이름 정하기
  • release-ver release/ver 등으로 짓는것이 관례

5. Hotfix Branch

• 출시 버전에서 발생한 버그를 수정하는 브랜치
  배포한 버전에서 긴급하게 수정을 해야할 경우, 'main' 브랜치에서 분기하는 브랜치.
  develop 브랜치에서 문제가 되는 부분을 수정해 배포 가능한 버전을 만들기는 시간도 많이 소요되고 안정성을 보장하기도 어렵다.
  바로 배포 가능한 main 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정, 다시 main브랜치에 병합하여 이를 배포한다.

1. 배포한 버전에서 긴급하게 수정을 해야하는 경우
   • main 브랜치에서 hotfix 브랜치 분기. (main에서 바로 분기한다.)
2. 문제가 되는 부분 빠르게 수정
3. 다시 main 브랜치에 병합하여 안정화된 버전 재배포.
   • 새로운 버전 이름으로 태그를 매김.
4. hotfix 브랜치에서의 변경 사항은 develop 브랜치에 병합함.

• 버그 수정만을 위한 브랜치이기 때문에, 다음 배포를 위해 개발하던 작업내용에 영향을 주지 않는다.
  hotfix 브랜치는 master 브랜치를 부모로 하는 임시 브랜치.

// main 브랜치에서 분기한다.
$ git checkout -b hotfix-x.x main
/ ~ 문제되는 부분 수정 ~ /
$ git checkout main               // 문제가 수정되고 안정화되면 main 브랜치로 이동
$ git merge --no-ff hotfix-x.x    // 브랜치 병합
$ git tag -a x.x                  // 버전태그 부여

// 브랜치 변경사항을 develop에도 적용
$ git checkout develop            // develop 브랜치로 이동 
$ git merge --no-ff hotfix-x.x    // 병합