git : git-flow strategy

출처

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423
https://techblog.woowahan.com/2553/

---

• master 브랜치는 항상 제품에 대한 안정적인 코드를 유지
• develop 브랜치는 새로운 기능의 개발이 진행되는 장소
• feature 브랜치는 새로운 기능을 개발하는 데 사용
• release 브랜치는 릴리스를 준비하고 테스트하기 위한 브랜치
• hotfix 브랜치는 프로덕션에서 발생한 긴급한 문제를 해결하기 위해 사용

---

Git Flow

Gitflow는 특징 브랜치와 여러 주요 브랜치를 사용하는 대안적인 Git 브랜칭 모델이다.
Gitflow는 개발자들 사이에서, 특히 협업시에는 매우 인기 있는 모델인데, 여러 개의 오래 지속되는 브랜치와 큰 커밋을 포함하는 것을 큰 특징으로 가지고 있다.

이는 기존의 trunk based 모델과 대조된다. trunk based 모델에서 개발자들은 feature 브랜치를 생성하고, 해당 기능이 완료될 때까지 주요 trunk 브랜치에 병합을 지연한다. 이렇게 오랜 시간 동안 지속되는 feature 브랜치는 병합하기 위해 더 많은 협력이 필요하며 주요 trunk 브랜치에서 벗어날 위험이 더 높고, 또한 충돌하는 업데이트를 도입할 수도 있는 취약점이 있다.

Gitflow는 예정된 릴리스 주기를 갖는 프로젝트 및 지속적인 배포의 DevOps 최상의 실천 방법으로 사용될 수 있는데, 이토록 gitflow 가 인기 있고, 권장되는 이유는 다음과 같다.

- 이 워크플로우는 특징 브랜치 워크플로우에서 요구되는 것 이상의 새로운 개념이나 명령을 추가하지 않는다. 
- 대신, 각 브랜치에 매우 구체적인 역할을 할당하고 상호 작용하는 방법과 시점을 정의한다. 
- feature 브랜치 외에도, 릴리스를 준비하고 유지하며 기록하기 위한 개별 브랜치를 사용한다. 
- 물론, feature 브랜치 워크플로우의 모든 이점을 활용할 수 있다: like 풀 리퀘스트, 격리된 실험 및 더 효율적인 협업.

Develop 및 Main 브랜치

오늘의 주인공은 프로젝트의 히스토리를 기록하기 위해 두 개의 브랜치를 사용한다. 단 하나의 브랜치를 사용하지 않는다.

• 메인 브랜치는 공식 릴리스 히스토리를 저장
• 개발 브랜치는 기능의 통합 브랜치로 작용

또한 메인 브랜치의 모든 커밋에 버전 번호를 태그하는 것이 편리하다.

첫 번째 단계는 기본 메인 브랜치에 개발 브랜치를 추가하는 것이다. 한 명의 개발자가 로컬에서 비어있는 develop 브랜치를 생성하고 이를 서버에 푸시하기만 하면 되는 간단한 작업이다:

git branch develop
git push -u origin develop

이렇게 만들어진 develop 브랜치는 프로젝트의 전체 히스토리를 포함하고, 메인은 축약된 버전을 포함할 것이다. 다른 개발자들은 이제 중앙 저장소를 복제하고 develop에 대한 트래킹 브랜치를 만들어야 한다.

git-flow 확장 라이브러리를 사용할 때는 기존 저장소에서 git flow init을 실행하면 develop 브랜치가 생성된다:

$ git flow init


Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []


$ git branch
* develop
 main

Feature 브랜치

Step 1. 저장소 생성

각 새로운 기능은 백업/협업을 위해 중앙 저장소로 푸시할 수 있는 자체 브랜치에 있어야 한다. 그러나 메인에서 브랜치를 만드는 대신, feature 브랜치는 develop 브랜치를 부모 브랜치로 둔다.
이후 기능이 완료되면 develop 브랜치에 병합된다.

feature branch 는 main branch 와 직접적으로 상호작용해서는 안된다.

주의: feature 브랜치와 develop 브랜치를 결합한 것은 실질적으로 feature 브랜치 워크플로우다. 
그러나 Gitflow 워크플로우는 이게 다가 아니다.

일반적으로 기능 브랜치는 최신 develop 브랜치에서 만들어집니다.

Feature 브랜치 생성

• 일반적인 git 사용시:

git checkout develop
git checkout -b feature_branch

• git-flow 확장 프로그램 사용시:

git flow feature start feature_branch

이후에는 평소에 git 을 사용하는 대로 쓰면 된다.

Feature 브랜치 완료

기능에 대한 개발 작업이 완료되었을 때, 다음 단계는 feature branch 를 develop branch 로 병합하는 것이다.

• 일반적인 Git 사용시:

git checkout develop
git merge feature_branch

• git-flow 확장 프로그램 사용시:

git flow feature finish feature_branch

Release 브랜치

develop branch 가 출시를 위해 충분한 기능을 확보했거나 미리 정해진 출시 날짜가 접근하면, develop에서 release 브랜치를 분기한다.
이 브랜치를 생성하면, 다음 릴리스 주기가 시작되므로 이 시점 이후에는 새로운 기능을 추가할 수 없다.

오직 버그 수정, 문서 생성 및 기타 출시와 관련된 작업만 수행된다. 릴리스 브랜치가 출시 준비가 완료되면, 해당 브랜치는 main에 병합되고 버전 번호가 태그로 지정된다. 또한, 릴리스가 시작된 후 develop branch 에도 병합된다.

릴리스를 준비하기 위해 전용 브랜치를 사용하면 한 팀이 현재 릴리스를 수정하는 동안 다른 팀이 다음 릴리스를 위한 기능 작업을 계속할 수 있는 이점이 있다. 또한 개발의 명확한 단계를 생성합니다

(예: "이번 주에는 4.0 버전을 준비 중입니다"라고 말하기 쉽고 실제로 저장소 구조에서 확인할 수 있다).

릴리스 브랜치를 만드는 것은 또 다른 간단한 브랜칭 작업이다. feature 브랜치와 마찬가지로 릴리스 브랜치는 develop 브랜치를 기반으로 하는데, 새로운 릴리스 브랜치를 만드는 방법은 다음과 같다.

• 일반적인 Git 사용시:

git checkout develop
git checkout -b release/0.1.0

• git-flow 확장 프로그램 사용시:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

릴리스를 출시할 준비가 되면, 해당 릴리스는 main 및 develop 으로 병합되고, 그 후 릴리스 브랜치는 삭제된다.
develop 으로 병합하는 것이 중요한데, 왜냐하면 릴리스 브랜치에 중요한 업데이트가 추가될 수 있으며, 이러한 업데이트는 새로운 기능에서 접근할 수 있어야 하기 때문이다.

만약 우리의 팀이나 조직이 코드 리뷰를 강조한다면, 여기 release branch 에 풀 리퀘스트를 요청하는 것이 이상적이다.

릴리스 브랜치를 완료하려면 다음과 같이 하면 된다.

• 일반적인 Git 사용시:

git checkout main
git merge release/0.1.0

• git-flow 확장 프로그램 사용시:

git flow release finish '0.1.0'

Hotfix 브랜치

유지 보수 또는 hotfix 브랜치는 프로덕션 릴리스를 빠르게 수정하기 위해 사용된다. hotfix 브랜치는 develop branch 대신 main branch 를 기반으로 하지만 release 브랜치와 feature 브랜치와 매우 유사하다.

이 브랜치는 main branch 에서 직접 분기되어야 하는 유일한 브랜치다. 수정이 완료되면, 해당 수정은 main branch 및 develop branch (또는 현재 release 브랜치)으로 병합되어야 하며, main branch 에는 업데이트된 버전 번호가 태그로 지정되어야 한다.

버그 수정을 위한 전용 개발 라인을 가지고 있으면, 팀이 나머지 워크플로우를 방해하지 않고 문제를 해결할 수 있으며, 다음 릴리스 주기를 기다릴 필요가 없다.

쉽게 말해서, 유지 보수 브랜치를 임시 release 브랜치로 생각할 수 있으며 이 브랜치는 main branch 와 직접 작업한다. hotfix 브랜치를 만드는 방법은 다음과 같다.

• git-flow 확장 프로그램을 사용하지 않을 경우:

git checkout main
git checkout -b hotfix_branch

• git-flow 확장 프로그램을 사용할 경우:

git flow hotfix start hotfix_branch

• release 브랜치를 완료하는 것과 유사하게, 핫픽스 브랜치는 main branch 와 develop branch 로 병합된다:

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
git flow hotfix finish hotfix_branch

요약

이 문서에서는 Gitflow 워크플로우에 대해 이야기 해봤다. Gitflow는 여러 가지 Git 워크플로우 스타일 중 하나, 이외에도 많은 git 워크플로우 스타일이 있다.
like forking workflow

Gitflow에 대해 알아야 할 몇 가지 주요 포인트다.

Gitflow 는 릴리스 기반 소프트웨어 워크플로우에 적합하다.
Gitflow는 프로덕션 환경에 대한 핫픽스 전용 채널을 제공한다.

Gitflow의 전반적인 흐름은 다음과 같다:

1. develop 브랜치가 main에서 생성
2. develop에서 릴리스 브랜치가 생성
3. develop에서 기능 브랜치가 생성
4. 기능이 완료되면 develop 브랜치로 병합
5. 릴리스 브랜치가 완료되면 develop과 main으로 병합
6. main에서 문제가 감지되면 main에서 핫픽스 브랜치가 생성
7. 핫픽스가 완료되면 develop와 main으로 병합

• Feature Branch Flow를 보여주는 완전한 예제:
  (main 브랜치가 설정된 리포지토리가 있다고 가정)

git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch

• 핫픽스 예제:

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch