Github/이해하기

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

adjh54 2023. 12. 28. 13:28
728x170
해당 글에서는 기존의 Git-flow 브랜치 전략을 기반으로 좀 더 간단한 방식으로 변형하여 사용하는 방법에 대해 알아봅니다.




 

💡 [참고] 기존에 실제 Git-flow 방식을 위해서 사용한 예시에 대해 변형한 방식입니다.

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

해당 글에서는 Git-flow 브랜치 전략을 기반으로 개발에서 릴리즈까지의 관리방법에 대해 확인해 봅니다. 💡 [참고] 해당 글을 읽기 전에 Git-flow 브랜치 전략 관련 글을 읽고 오시면 도움이 됩니다

adjh54.tistory.com

 
 
 

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/

 

💡 [참고] Git 브랜치 전략에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

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

해당 글에서는 Git을 관리하기 위한 Git Branch Strategy로 Git-flow, Github-flow, Gitlab-flow, TBD 방식에 대해서 알아봅니다. 1) Git 브랜치 전략(Git Branch Strategy) 💡 Git 브랜치 전략(Git Branch Strategy) - Git 저장소

adjh54.tistory.com

 
 
 

2) 깃 플로우(Git Flow)를 변형한 간단한 사용방법


💡 깃 플로우(Git Flow)를 변형하기

- 깃 플로우 방식은 중대형 프로젝트에 적합한 브랜치 전략입니다. 이에 대해 소규모 프로젝트에도 용이하게 사용이 가능하도록 변형한 방법에 대해 공유합니다.
- 직접 개발에서 운영까지 직접 관리하고 운영을 하였을 때, 크지 않은 규모에 사용하기에 적합하기 이에 따라 확인해 봅니다.

 

1. 변형된 브랜치 구성


💡 변형된 브랜치 구성

- 이전 Gitflow 방식과 비교하였을 때, main 브랜치와 hotfix 브랜치는 병합하거나 생략을 하였습니다.

1. main 브랜치
- main 브랜치는 develop 브랜치로 대체하며 default 브랜치로 사용합니다.
- 또한 develop 브랜치의 역할로 QA서버나 개발서버에 올리기 위한 목적으로 사용이 됩니다.

2. hotfix 브랜치
- 크지 않은 프로젝트 규모에서는 hotfix 브랜치를 관리하지 않고 즉각 처리할 수 있기에 해당 브랜치는 생략하였습니다.
브랜치 이름설명
feature- 새로운 기능을 개발할 때 사용하는 브랜치입니다.
- develop 브랜치에서 분기되어 사용됩니다.
develop(=default)- default branch이자 Feature Branch들이 병합되는 브랜치를 의미합니다.
- 주된 역할은 QA서버나 개발 서버에 올리기 위해 한곳에 모이는 브랜치입니다.
- 또한 해당 브랜치로 Pull Request가 수행되면 CI/CD로 QA서버나 개발서버에 배포되는 브랜치입니다.
release- 제품 출시 버전을 관리하는 브랜치입니다.
hotfix- 긴급한 버그 수정이 필요할 때 사용하는 브랜치입니다. master 브랜치에서 분기합니다. 
main- 제품 출시 버전을 관리하는 브랜치입니다.

 
 
 

2. 변형된 브랜치 흐름


💡 변형된 브랜치 흐름

1. develop branch
- 브랜치의 시작은 develop 브랜치에서 시작합니다.
- 해당 소스코드는 QA서버나 개발서버에 올라갈 소스코드를 관리하며, 가장 최신의 소스코드를 유지합니다.


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


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


4. [CASE2] feature branch → (Pull Request) → develop branch
- 최종 병합된 소스코드를 develop branch로 pull Reuqest를 수행하면 Github Actions의 CI/CD 툴을 이용하여 develop branch로 Pull Request 동작이 수행되면 QA서버나 개발서버에 배포가 됩니다.


5. release branch
- release branch에서는 운영 서버에 배포를 하는 소스코드를 관리합니다.


6. develop branch → (Merge) → release branch
- QA서버나 개발서버에서 테스트가 완료된 브랜치를 release branch로 병합을 합니다.
- 이전 QA서버나 개발 서버에서 CI/CD로 자동 배포 되었던 부분과 다르게 release branch는 직접 수동으로 소스코드를 내려서 배포를 수행합니다.

 
 
 

상세 처리과정 -1: Develop Branch


💡 Develop Branch

- 브랜치의 시작은 develop 브랜치에서 시작합니다.
- 해당 소스코드는 QA서버나 개발서버에 올라갈 소스코드를 관리하며, 가장 최신의 소스코드를 유지합니다.

 
 

💡 또한 default branch로 ‘develop branch’를 사용합니다.

 
 
 
 

상세 처리 과정-2: develop branch → feature branch


💡 Develop branch → Feature branch

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

 

💡 JIRA 이슈 기반 Feature Branch 생성

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

 
 
 

💡 Github에서 사용예시

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

 
 

💡 JIRA에서 사용 예시

- JIRA에서는 이슈의 상태도 ‘진행 중’으로 바꾸었습니다.

 
 
 

상세 처리과정-3: [CASE1] feature branch → (Merge) → develop branch


 💡 feature branch → (Merge) → develop branch

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

 
 

💡 JIRA에서 사용예시

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

 
 

💡 Github에서 사용예시

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

 
 
 

상세 처리과정-4: [CASE2] feature branch → (Pull Request) → develop branch


💡 feature branch → (Pull Request) → develop branch

- 최종 병합된 소스코드를 develop branch로 pull Reuqest를 수행하면 Github Actions의 CI/CD 툴을 이용하여 develop branch로 Pull Request 동작이 수행되면 QA서버나 개발서버에 배포가 됩니다.

 

 

 💡 Github 사용예시

- ‘MF-5 로그인 기능 구현’이라는 브랜치는 develop branch와 동일한 소스코드입니다.
- 이러한 소스코드를 Pull Request를 수행합니다.

 
 

 💡 Github 사이트에서 예시-1

- Pull requests 탭에 ‘New pull request’ 버튼을 누릅니다.

 
 

💡 Github 사이트 예시-2

- ‘MF-5 로그인 기능 구현’이라는 feature branch를 develop branch로 강제 ‘Pull Reuqests’를 수행함으로써 CI/CD를 발생시킵니다.

 
 

💡 Github 사용예시

- Merge pull Reuqest가 수행됨을 확인할 수 있습니다. 또한 CI/CD로 QA서버나 개발서버에 배포된 상태입니다.
- 이렇게 쉽게 테스트를 해볼 수 있는 서버로 배포가 완료되었습니다.

 
 

💡 [참고] Github Github Actions에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

[Github] Github Actions 이해하기-1 (정의, 주요 용어)

해당 글에서는 CI/CD 중 하나인 Github Actions에 대해서 이해하고 각각의 용어에 대해 이해하는 글을 다루고 있습니다. 1) Github Actions란?💡 GitHub의 기능 중 하나로 특정 '이벤트에 따라 자동으로 작동

adjh54.tistory.com

[Github] Github Actions 이해하기-2 (환경설정, 적용 예시)

해당 글에서는 이전 용어들에 대해서 이해하는 것에 이어진 환경 설정 후 적용하는 예시에 대해서 이해하기 위한 글을 다루고 있습니다. 💡 이전에 작성한 Github Actions 정의 및 주요 용어를 설명

adjh54.tistory.com

 
 
 

상세 처리과정-5: release branch


💡 release branch

- release branch에서는 운영 서버에 배포를 하는 소스코드를 관리합니다.

 

💡 Github에서 사용예시

- 아래와 같이 실제 운영서버에 반영을 위해 소스코드가 관리됩니다. 태그로 관리가 되어서 실제 운영에 반영된 버전을 확인합니다.

 
 
 
 
 

상세 처리과정-6: develop branch → (Merge) → release branch


💡 develop branch → (Merge) → release branch

- QA서버나 개발서버에서 테스트가 완료된 브랜치를 release branch로 병합을 합니다.
- 이전 QA서버나 개발 서버에서 CI/CD로 자동 배포 되었던 부분과 다르게 release branch는 직접 수동으로 소스코드를 내려서 배포를 수행합니다.

 
 

💡 Github에서 사용예시 -1

- 개발 서버에서 테스트를 완료한 후에 새로운 버전을 배포하기 위해서라면 develop 브랜치에서 Release Branch는 분기하여 구성합니다.

 
 
 

 💡 Github에서 사용예시 -2

- 운영서버에 배포를 위해 ‘태그’를 추가하여 릴리즈를 구성합니다.

 
 
 

💡 Github 사이트에서 사용예시 -1

- Github 사이트 내에서 Release 탭을 선택합니다.

 
 
 
 

💡 Github 사이트에서 사용예시 -2

- ‘Draft a new release’ 버튼을 눌러서 새로운 릴리즈를 구성합니다.

 
 
 
 

 💡 Github 사이트에서 사용예시 -3

- 생성한 태그를 기반으로 릴리즈를 구성합니다.

 
 
 
 

💡 Github 사이트에서 사용예시 -4

- 구성이 완료됨을 확인할 수 있습니다.

 
 
 
 

💡 Github 사이트에서 사용예시 -5

- 해당 소스코드를 직접 다운로드하여서 운영서버에 배포를 합니다.

 
 
 
 
 
 
 
오늘도 감사합니다. 😀
 
 
 

그리드형