[브랜치 전략] Git hub flow, Git flow 워크플로우 비교

Github flow와 Git flow는 Git 기반의 브랜치 전략 워크 플로우 입니다.

개발팀 조직의 규모나 니즈에 맞게, 선택해서 사용 하는 것이 일반적 입니다.

 

Github flow

기본적인 브랜치 전략으로, 단순하고 간결하며, 지속적인 배포에 중점을 둔 워크 플로우 입니다.

 

주요 브랜치로는 Main 브랜치, Feature 브랜치, State/Production 브랜치 (Optional) 가 있다.

 

📂 Github Workflow

1) Feature 브랜치에서 기능 개발

 

2) Feature 브랜치에서 Main 브랜치로 Pull Request 및 Merge 

 

3) Main 브랜치에서 Stage 브랜치나 Production 브랜치로 최종 Merge

- 여기서 Stage나 Production 브랜치는, 운영되고 있는 Stage 서버, Production 서버의 의미도 가질 수 있습니다.

 

4) 급한 수정이 필요할 때 Feature/Main 브랜치에서 Hotfix 하여 반영 가능

 

해당 방법은, 작은 단위로 빈번하게 배포가 필요한 상황에서 적절한 브랜치 전략이다.

출처:https://escapefromcoding.tistory.com/746

 

Git flow

Git flow 브랜치 전략은 조금 더 복잡한 워크플로우를 가지며, 보다 큰 단위로 일정 주기마다 배포하는 브랜치를 뜻합니다. 

 

주요 브랜치로는 Master(main) 브랜치, Develop 브랜치, Release 브랜치, Hotfix 브랜치, Feature 브랜치가 있습니다.

 

📂  Git flow Workflow

1) Feature 브랜치에서 기능 개발

- git flow feature start

 

2) Feature 브랜치에서 Develop 브랜치로 Pull Request 및 Merge

- git flow feature finish

 

3) Develop 브랜치에서 특정 Tag 버전을 가진 Release Branch 생성

- git flow release start v1.0.0

 

4) Release 브랜치에서 Master로 Merge 하고, 특정 Tag 버전을 가진 Master 버전이 생김

- git flow release finish v1.0.0

 

5) 혹여 Release 에서 추가 Commit 이 쌓였다면(추가적인 수정), Develop에도 Merge 함

- git flow release finish v1.0.0

 

6) 최종 Master에서는 특정 Tag 버전별로 코드가 생성되며, 상황에 맞게 특정 버전을 배포함

 

7) 급한 수정 발생시, Hotfix 브랜치를 생성하고 작업을 해결하면, Master 브랜치와 Develop에 Merge 를 진행함

- git flow hotfix start, git flow hotfix finish

 

Git flow는 Develop에 기반한 다양한 Release 버전 관리와, 버그 발생시 핫픽스 등의 여러 상황에 대처하기 위해, 더 많은 단계와 브랜치를 활용하여 안정성을 높여줍니다. 

하지만 단계가 많은 만큼 브랜치 히스토리가 복잡해 질 수 있고, 조금 더 큰 규모의 팀이나 복잡한 프로젝트에 유용 할 수 있습니다.

 

출처: https://escapefromcoding.tistory.com/746

 

Git flow 전략 선택과 CI-CD 를 적용한 워크플로우

프로젝트 간 최종적으로 브랜치 전략은 Git flow를 선택했고, Git은 Bigbucket, CI, CD는 Jenkins 로 구성하였고,

 

최종적으로 Git flow - Bitbucket - Jenkins 를 포함한 전체 워크 플로우를 한 번 나열해 보려고 한다. 

상세 환경은 다음과 같다. 로컬 (개인 작업 환경) , 원격(Bitbucket), Jenkins (EC2) 

 

📂 전체 Workflow

1. 로컬에서 프로젝트를 clone 받고, git flow init 으로 git flow를 적용한다.

 

2. 로컬 develop Feature 브랜치 만들어서 작업을 시작한다.

- git flow feature start <branch 명>

 

3. 로컬 feature/ 에서 작업 후(commit) 원격으로 push 한다.

- 원격으로 push 하기 전 테스트 코드를 로컬에서 수행하여 1차적으로 feature/ 를 검증한다.

 

4. 원격 feature/ -> develop 으로 PR을 생성하고 코드 리뷰를 진행한다.

- 코드 리뷰 간 수정 사항 있으면 재 작업 후 3. 을 반복한다.

 

5. 승인된 원격 feature/ 를 Merge

- Merge 할 때 Bitbucket의 Webhook을 통해 Jenkins의 CI Job이 호출되고 수행된다. 

 

6. Jenkins의 CI Job에서는 테스트 코드 수행 및 배포 전 필요한 테스트를 진행한다.

- Jenkins에서 실패시, develop 혹은 feature에서 빠르게 수정하거나(CI 재진행), Merge를 취소 한다.

- Jenkins에서 성공하면, 로컬 develop에 pull을 받아 최신화 한다.

 

7. 특정 tag버전을 가진 release branch를 생성 한다.

- git flow release start v1.0.0

- 자동으로 해당 release/v1.0.0 의 branch로 checkout 된다.

 

8. 문제가 없다면 release를 publish (원격에 push) 한다.

- git flow release publish v1.0.0

 

9. release를 종료한다.

- git flow release finish v1.0.0

- 로컬에서 develop과 main에 merge되고 현재 commit을 바라보는 특정 tag가 생성 된다.

- 해당 과정에서 필요시 WebHook을 이용해, 배포 서비스에 대해 Jenkins에서 추가 CI (테스트, 빌드 등)를 진행한다.

 

10. 로컬에서 최종 merge 된 main, develop 그리고 tag를 원격으로 push 한다.

- git push origin --tags

- 원격에서 해당 tag 버전으로 생성된 것을 알 수 있다.