[Github] Git-flow 브랜치 전략을 이용한 사용 예시(with. JIRA)

해당 글에서는 Git-flow 브랜치 전략을 기반으로 개발에서 릴리즈까지의 관리방법에 대해 확인해 봅니다.

💡 [참고] 해당 글을 읽기 전에 Git-flow 브랜치 전략 관련 글을 읽고 오시면 도움이 됩니다.

[Github] Git 브랜치 전략(Git Branch Strategy) : Git Flow, Github Flow, GitLab Flow, TBD

 
 
 

1) 깃 플로우(Git Flow)

---

💡 깃 플로우(Git Flow)

- 중대형 프로젝트에 적합한 전략으로 병렬 개발을 위한 전략으로 주로 사용이 됩니다.

- 해당 전략은 ‘Vincent Driessen’이 2010년도에 제안한 방식으로 기능 개발과 유지보수를 위한 브랜치 전략을 제공합니다.

 

1. 주요 브랜치

---

브랜치 이름	설명
master	제품 출시 버전을 관리하는 브랜치입니다.
develop	다음 출시 버전을 개발하는 브랜치입니다.
feature	새로운 기능을 개발할 때 사용하는 브랜치입니다. develop 브랜치에서 분기합니다.
release	다음 출시 버전을 준비하는 브랜치입니다.develop 브랜치에서 분기합니다.
hotfix	긴급한 버그 수정이 필요할 때 사용하는 브랜치입니다. master 브랜치에서 분기합니다.

 
 
 
 

2. 브랜치의 흐름

---

💡 깃 플로우(Git Flow) 브랜치의 흐름

1. develop branch
- develop 브랜치에서 시작합니다. 이 브랜치는 개발 중인 최신 코드를 포함하고 있습니다.


2. develop branch → feature branch
- 기능 개발을 위해 개발자마다 feature 브랜치를 생성합니다.
- feature 브랜치는 develop 브랜치에서 분기되며, 개별 기능 개발을 위한 작업을 진행하는 데 사용됩니다.

3. feature branch → (Merge) → develop branch
- 기능 개발이 완료되면 feature 브랜치를 develop 브랜치로 병합합니다.
- 이를 통해 새로운 기능이 develop 브랜치에 통합됩니다.


4. release branch
- release 브랜치를 생성하여 다음 릴리즈를 준비합니다.
- 여기서는 버그 수정, 문서 업데이트 및 준비된 기능에 대한 마지막 테스트를 수행합니다.


5. release branch → (Merge) → develop branch
- release 브랜치가 안정화되면, develop 브랜치에 release 브랜치를 병합합니다.
- 이로써 준비된 기능들이 develop 브랜치로 통합됩니다.


6. develop branch → (Merge) → main branch
- 최종적으로, develop 브랜치의 코드를 Main 브랜치로 병합하여 새로운 릴리즈를 생성합니다.


7. main branch
- main 브랜치에 있는 코드는 안정적인 상태로 간주되어 프로덕션 환경에 배포됩니다.


8. main branch → horfix branch → main branch
- 릴리즈 된 main 브랜치에서 긴급하고 중요한 버그 수정 또는 보안 문제를 해결하기 위해 사용됩니다.
- main 브랜치에서 분기되어 개발 및 테스트 환경에서 수정 작업을 수행한 후 ‘main’ 브랜치에 안전하게 병합이 됩니다.

https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/

 
 
 

상세 처리과정 -1: Develop Branch

---

💡 develop branch

- 소스코드의 시작은 develop 브랜치에서 시작합니다. 이 브랜치는 개발 중인 최신 코드를 포함하고 있습니다.

 
 
 

상세 처리과정-2: Develop Branch → Feature Branch

---

 💡 Develop Branch → Feature Branch

- Feature Branch에서는 기능 개발을 위한 브랜치입니다.
- 새로운 기능을 추가하기 위해 Develop 브랜치에서 Feature 브랜치를 따고, 작업이 완료되면 Develop 브랜치로 병합됩니다.

 
 

💡 JIRA 이슈 기반 Feature Branch 생성

- JIRA 이슈를 기반으로 Feature Branch를 생성합니다. 하나의 이슈당 하나의 브랜치로 구성을 합니다.
- Feature Branch의 경우 ‘Develop Branch’에서 파생이 되어 생성됩니다.
- 아래와 같이 JIRA의 이슈들이 존재하고 각각의 담당자들이 이슈별 기능을 담당하여 개발을 수행합니다.

 
 

💡 [참고] JIRA - Github 연동 방법

[Github] JIRA - Github 연동 및 Github 소스트래킹 방법

 
 

💡 Github에서 사용예시

- 아래와 같이 MF-1, MF-2, MF-3 JIRA의 키 값을 기반으로 브랜치를 생성하고 ‘MF-1, MF-2, MF-3’ 형태로 커밋을 수행하였습니다.

 
 
 

💡 위와 같이 커밋 메시지로 ‘MF-2 의존성 주입 변경’이라는 메시지로 커밋을 하게 되면 JIRA에서 이에 대한 소스 트래킹을 수행할 수 있습니다.

- 소스 트래킹에서는 커밋을 한 브랜치와 커밋 내용에 대해서 확인이 가능합니다.

 
 

[ 더 알아보기 ]

💡 소스 트래킹

- 소프트웨어 개발 및 유지 보수 과정에서 소스 코드의 변경 이력을 추적하는 것을 말합니다.
- 이를 통해 개발자들은 코드 변경 사항을 관리하고 버그를 해결하며, 효율적인 협업과 소프트웨어 개발 과정의 투명성을 유지할 수 있습니다.

 
 
 

상세 처리과정-3: Feature Branch → (Merge) → Develop Branch

---

💡 feature branch → (Merge) → develop branch

- 기능 개발이 완료되면 feature 브랜치를 develop 브랜치로 병합합니다. 이를 통해 새로운 기능이 develop 브랜치에 통합됩니다.
- 이러한 작업을 통해 각각 개발자가 진행하던 기능들이 develop Branch로 합쳐집니다.

 
 

💡 JIRA에서 사용예시

- JIRA 내에서 이슈들이 모두 ‘완료’된 상태입니다. 그렇기에 소스코드 내에서 하나의 소스로 합쳐지는 작업이 필요합니다.

 
 

💡 Github에서 사용예시

- 아래의 예시에서는 MF-1, MF-2, MF-3 이슈들에 대해서 ‘develop-multiflex’라는 Develop Branch에 병합을 하였습니다.

 
 
 
 

상세 처리과정-4: Release Branch

---

💡 Release Branch

- release 브랜치를 생성하여 다음 릴리즈를 준비합니다.
- 여기서는 버그 수정, 문서 업데이트 및 준비된 기능에 대한 마지막 테스트를 수행합니다.

 
 

[ 더 알아보기 ]

💡 릴리즈(Release)란?

- 소프트웨어나 제품의 새로운 버전을 공개하는 것을 말합니다. 이는 기능 개선, 버그 수정, 보안 강화 등을 포함할 수 있습니다.
- 릴리즈는 사용자들에게 최신 업데이트를 제공하고 제품을 개선하는 데 중요한 역할을 합니다.

 
 

💡 JIRA에서 사용예시

- 다음 릴리즈를 준비하기 위한 대기 브랜치로 새로운 버전을 릴리스하기 위한 소스코드가 대기 중입니다.

 
 
 

상세 처리과정-5: Release Branch → (Merge) → Main branch

---

💡 Release Branch → (Merge) → Main branch

- 최종적으로, Release 브랜치의 코드를 Main 브랜치로 병합하여 새로운 릴리즈를 생성합니다. 

 

 [더 알아보기]

💡 그림에서는 master 브랜치라고 이야기하는데 왜 Main 브랜치라고 여기서는 적었는가?

- Github의 기본 브랜치 이름이 ‘master’에서 ‘main’으로 변경되었습니다. 이 변경은 더 포용적인 언어를 촉진하고 노예제와 관련된 어떠한 언급도 없애기 위해 변경되었습니다.

 

💡 Main 브랜치의 경우는 Github 내에 ‘default’ 브랜치를 의미합니다.

 
 
 

💡 아래의 작업을 통해 Release Branch의 소스코드를 main 브랜치(=default)에 병합하였습니다.

 
 
 

상세 처리과정-6: Main Branch

---

💡 Main Branch

- Main 브랜치에 있는 코드는 안정적인 상태로 간주되어 프로덕션 환경에 배포됩니다.
- 또한 릴리즈가 되는 버전에서는 태그를 추가합니다.

 
 

💡 Github 사용예시

- 릴리즈 출시를 위한 대기의 main 브랜치에 v0.0.2라는 것을 명시하기 위해 태그를 추가합니다.

 
 
 

💡 [참고] Tag 및 릴리즈를 위한 버전관리 방법에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

[Github] Tag 및 Releases를 통한 버전관리 방법

 
 

💡 위에서 추가한 태그는 Github의 Repository에서 릴리즈 버전을 구성할 수 있습니다.

 
 

💡 아래와 같이 생성한 태그를 기반으로 릴리즈 노트를 작성하여 ‘Publish release’를 수행합니다.

 
 

💡 아래와 같이 릴리즈 버전을 관리할 수 있습니다.

 
 
 

상세 처리과정-7: Main Branch → Hotfix Branch → Main Branch

---

💡 Main Branch → Hotfix Branch → Main Branch

- 릴리즈 된 main 브랜치에서 긴급하고 중요한 버그 수정 또는 보안 문제를 해결하기 위해 사용됩니다.

- main 브랜치에서 분기되어 개발 및 테스트 환경에서 수정 작업을 수행한 후 ‘main’ 브랜치에 안전하게 병합이 됩니다.
- hotfix 브랜치를 사용하면 main 브랜치의 안정성을 유지하면서 문제를 신속하게 해결할 수 있습니다.**

 
 

💡 hotfix 브랜치에서 develop 브랜치로 분기가 되어서 즉각적인 수정을 수행합니다.

 
 

💡 develop 브랜치에서 release 브랜치로 병합을 합니다.

 
 

💡 release 브랜치에서는 main 브랜치로 병합하고 긴급 새로운 릴리즈를 추가합니다.

 
 
 
 

💡[참고] 해당 Git-flow 방식을 변형한 방식에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

[Github] Git-flow 브랜치 전략을 변형한 간단한 사용방법(with. JIRA)

 
 

💡 [참고] Github에 더 궁금하시면 아래의 링크를 참고하시면 도움이 됩니다.

주제	링크
Github 주요 용어 -1: 기본 구조	https://adjh54.tistory.com/22
Github 주요 용어-2 : 기본 동작	https://adjh54.tistory.com/363
Github - JIRA 연동 방법	https://adjh54.tistory.com/366
Git Tag 및 Release 구성 방법	https://adjh54.tistory.com/13
Github Actions-1: 정의, 주요용어	https://adjh54.tistory.com/50
Github Actions-2: 환경설정, 적용예시	https://adjh54.tistory.com/51
Git 브랜치 전략의 종류	https://adjh54.tistory.com/364
Git 브랜치 전략 : Git-flow	https://adjh54.tistory.com/367
Git 브랜치 전략 : Git-flow 변형	https://adjh54.tistory.com/368

 
 
 
 
 
 
 
오늘도 감사합니다. 😀