GIT 브랜치 전략 - Git-flow, Github-flow

GIT 브랜치 전략으로는 많이 사용하는 Git-flow, Github-flow가 있다. 

✅ Git flow란

• 브랜치를 효울적으로 관리하기 위해 사용하는 브랜치 관리 전략
  • git flow, github flow, gitlab flow 전략 등 다양하게 있다
• 브랜치를 어떻게 운영할 것인가에 관한 사례, 프로그램이다.
• master, develop, feature(기능개발), release(출시), hofix(긴급한 수정사항)

• 장점
  • 브랜치별로 역할을 명확히 나누는 규칙성
  • 디테일한 버전 정보 제공
  • master 브랜치의 코드는 깔끔한 상태 유지(테스트 후 최종 수정된 것만 반영)
• 단점
  • 많은 브랜치로 생기는 복잡한 규칙

 

✅ Git Repository 구성

Repository는 아래 3가지로 구분한다.

1. Upstream Remote Repository
   • 개발자들이 공유하는 저장소로, 최신 소스코드가 있는 원격 저장소
2. Origin Remote Repository
   • upstream remote repository를 fork한 원격 개인 저장소
3. Local Repository
   • 개인 컴퓨터에 있는 저장소

[작업 방식]

local repo에서 작업을 완료한 뒤, 작업 브랜치를 origin repo에 push한다.

origin repo에 push한 브랜치를 upstream remote repo로 merge하는 pr를 생성 → 코드리뷰 → merge 로 진행한다.

새로운 작업을 시작할 때는 local에서 upstream remote repo를 pull해서 가져온다.

 

fork한 레포지토리를 따로 두면, 개발자들이 하는 작업이 모두가 공유하는 upstream remote repo로 바로 올라가는 것이 아니기에 위험이 덜하다.

 

✅ Git Branch

Git Flow에서 사용하는 5가지의 브랜치 - 항상 유지되는 메인브랜치(master, develop)와 일정 기간 유지되는 보조 브랜치(feature, release, hostfix)

 

1. master

• 제품으로 출시될 수 있는 브랜치

 

2. develop

• 다음 출시 버전을 개발하는 브랜치

 

3. feature

• 기능 개발용 브랜치

• 가지가 뻗어 나오는 곳 : develop
• 가지가 다시 합쳐지는 곳 : develop
• 새로운 기능을 추가할 때 주로 사용하는 가지이다.
• 이름 설정 : master, develop, release-*, hotfix-*를 제외하고 자유롭게 설정가능
  • feature/기능요약의 형식을 추천 ex. feature/login

// feature 브랜치(feature/login)를 'develop' 브랜치에서 분기
$ git checkout -b feature/login develop

/* feature/login에 관한 작업 수행 */

// feature 브랜치에서 모든 작업이 끝나면 'develop' 브랜치로 이동한다.
$ git checkout develop

// 'develop' 브랜치에 feature/login 브랜치 내용을 merge한다.
# --no-ff 옵션: 아래에 추가 설명
$ git merge --no-ff feature/login

// -d 옵션: feature/login에 해당하는 브랜치를 삭제한다. -> 이건 선택사항
$ git branch -d feature/login

// 'develop' 브랜치를 원격 중앙 저장소에 올린다.
$ git push origin develop

• —no-ff 옵션
  • 새로운 커밋 객체를 만들어 develop 브랜치에 merge한다.
  • feature 브랜치에 존재하는 커밋기록을 모두 합쳐서 새로운 커밋 객체를 만들어 develop 브랜치로 merge한다.

 

 

4. release

• 이번 출시 버전을 위한 브랜치(제품을 배포하고자 할 때 사용)
• 가지가 뻗어 나오는 곳 : develop
• 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : release-*
  • release-* 형식을 추천 ex. release-1.2
• 배포 가능한 상태가 되면 master브랜치로 merge하고, 출시된 master 브랜치에 버전 태그를 추가한다. release 브랜치에서 기능을 점검하며 발생한 수정사항은 develop에도 merge해줘야 한다.

// release 브랜치(release-1.2)를 'develop' 브랜치에서 분기
$ git checkout -b release-1.2 develop

/* 배포 사이클 시작 */

// release 브랜치에서 배포 가능한 상태가 되면 'master' 브랜치로 이동한다.
$ git checkout master

// 'master' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
$ git merge --no-ff release-1.2

// 병합한 커밋에 Release 버전 태그를 부여한다.
$ git tag -a 1.2

// 'release' 브랜치의 변경 사항을 'develop' 브랜치에도 적용해야 하기에, 'develop' 브랜치로 이동
$ git checkout develop

// 'develop' 브랜치에 release-1.2 브랜치 내용을 merge한다.
$ git merge --no-ff release-1.2

// -d 옵션: release-1.2에 해당하는 브랜치를 삭제한다.
$ git branch -d release-1.2

 

 

 

5. hotfix

• 출시 버전에서 발생한 긴급한 버그를 수정하는 브랜치
• 가지가 뻗어 나오는 곳 : master
• 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : hotfix-*
• hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 적용시켜준다. 주로 버그가 생기면 이를 해결하기 위해 생성되기에, 해결된다면 보통 제거하는 일회성 가지이다.

// release 브랜치(hotfix-1.2.1)를 'master' 브랜치(유일!)에서 분기
$ git checkout -b hotfix-1.2.1 master

/* 버그 수정 */

// 'master' 브랜치로 이동한다.
$ git checkout master

// 'master' 브랜치에 hotfix-1.2.1 브랜치 내용을 merge한다.
$ git merge --no-ff hotfix-1.2.1

// 병합한 커밋에 새로운 버전 이름으로 태그를 부여한다.
$ git tag -a 1.2.1

// 'hotfix' 브랜치의 변경 사항을 'develop' 브랜치에도 적용해야 하기에, 'develop' 브랜치로 이동
$ git checkout develop

// 'develop' 브랜치에 hotfix-1.2.1 브랜치 내용을 merge한다.
$ git merge --no-ff hotfix-1.2.1

 

흐름

 

1. 새로운 기능 추가 작업이 생긴 경우, develop 브랜치에서 feature 브랜치를 생성한다.

2. 기능 추가 작업이 완료되면, feature브랜치는 develop브랜치로 merge된다.

3. develop 브랜치에 모든 기능이 merge 되었다면, QA(테스트. 품질 관리 및 개선)를 위해 develop 브랜치에서 release 브랜치를 생성한다.

4. QA를 진행하며 생긴 버그들은 release 브랜치에 수정된다. 이후 release 브랜치를 master, develop으로 merge한다.

5. 마지막으로, 출시된 master 브랜치에 버전 태그를 추가한다.

6. 배포된 서버에서 버그가 발생하면, hotfix 브랜치를 생성하여 수정해주고, 수정사항을 master와 develop 양쪽에 merge하여 동기화 시켜준다.

• 버전 태그?
  • 버전은 주로 x.x.x의 형태이다.
  • 가장 첫번째 숫자는 Major Version으로, 1로 시작해서 소프트웨어 전체적으로 큰 변화가 생겼을 때 버전 업을 한다.
  • 두번째 숫자는 Minor Version으로, 0으로 시작해 없던 기능의 추가나 수정의 변화가 발생했을 때 버전 업을 한다.
  • 마지막 세번째 자리는 Build or Maintenance Version으로, 0으로 시작해 자잘한 버그나 내부적으로 코드 보안 등의 변화가 생겼을 때 버전업을 한다, (생략하는 경우도 있음)
• 정상적인 프로젝트를 진행하기 위해서는 master, develop branch를 모두 운용해야 하며, 나머지 브랜치(feature, release, hotfix branch)는 사용하지 않는다면 지우고 해당 브랜치를 사용해야할 상황이 왔을 때 만들어줘도 된다.
• 대부분의 작업은 develop에서 취합하며, 테스트를 통한 변동사항이 없는 최종 결과물을 master로 merge해준다.

 

 

 

✅ Github-flow

 

 

• Github-flow에서는 체계적인 브랜치 분류가 없기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 중요하다. 기본적으로 master 브랜치에 대한 규칙만 있다면 나머지 브랜치들에 대해서는 특별히 관여하지 않으며, pull request 기능을 사용할 것을 권장한다.
• 자동화 개념이 들어가 있다는 특징을 가지며, 자동화가 적용되지 않은 곳이라면 수동으로 진행해준다.
• feature나 develop 브랜치가 존재하지 않으며, master 브랜치는 항상 최신 상태이며 product에 배포되는 브랜치이다. 

 

1. 개발을 진행하며 커밋 메시지를 명확하고 상세하게 적어준다.

2. 작업 완료 후 PR을 생성하여 코드 리뷰와 테스트를 거친 후, master 브랜치로 merge한다.

3. GIthub-flow에서는 master 브랜치가 가장 최신 브랜치이기에, 배포 자동화 도구를 통해 즉시 배포시킨다.

    → master로 merge가 일어나면 자동으로 배포되도록 설정해놓는다.(CI/CD)