Git Flow vs Github Flow

회사 내에서 진행 중인 프로젝트는 Git을 통해 소스관리가 이루어 집니다.

특별히 이번에 Git을 통해 프로젝트를 관리하는 방법에 대해 공부를 하는 시간을 가졌습니다.

그 중 Git Flow와 Github Flow에 대해서 알아봅시다.

---

1. Git Flow

Git Flow는 소프트웨어 개발의 각 단계를 쉽게 관리하기 위해 여러가지 브랜치를 갖습니다.

( 만들어진 기능을 쉽게 추적. 릴리즈 단계가 있어 프로덕션 문제를 신속하게 수정하는 데 도움. 빠르게 버그를 고치는 데 도움.)

이 방법은 ‘release’라는 단계가 있는 소프트웨어를 개발할 때 효율적입니다. 만약, 지속적인 배포 환경이라면 맞지 않는 방법입니다. 보통 명확한 버전이 있는 소프트웨어를 구축할 때, 사용되어지는 방법입니다.

주된 브랜치는 다음과 같습니다

1. master

• 언제든지 운영환경에 배포할 수 있는 소스 코드를 가지는 브랜치

2. develop

• 다음 release를 위해 가장 최근에 개발된 소스 코드를 가지는 브랜치

3. features

• 새로운 기능을 개발하는 데 사용하는 브랜치 
• 개발자의 개인 local영역에만 존재 
• //Features branches are created from the develop branch $ git checkout -b myfeature develop $ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop
• merge 시 —n-ff 문장 사용 (이력관리를 해야되기 때문에)

4. hotfix

•  현재 실행중인 배포된 환경에서 bug가 발견된 후, 코드를 수정할 때 사용되는 브랜치 
•  분기 후, 버전 정보를 올려야 함 ex) 1.2 → 1.2.1

  $ git checkout -b hotfix-1.2.1 master
    Switched to a new branch "hotfix-1.2.1"
  $ ./bump-version.sh 1.2.1
    Files modified successfully, version bumped to 1.2.1.
  $ git commit -a -m "Bumped version number to 1.2.1"
    [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
    1 files changed, 1 insertions(+), 1 deletions(-)
  $ git commit -m "Fixed severe production problem"
  
  $ git checkout master
    Switched to branch 'master'
  $ git merge --no-ff hotfix-1.2.1
    Merge made by recursive.
    (Summary of changes)
  $ git tag -a 1.2.1
  
  $ git checkout develop
    Switched to branch 'develop'
  $ git merge --no-ff hotfix-1.2.1
  
  $ git branch -d hotfix-1.2.1
  

• 예외 사항으로, release branch가 현재 존재할 경우 develop 브랜치로 가서 merge하기 보다, release 브랜치에서 merge 하면 됨.

5. release

• 새로운 프로덕션 릴리스 준비를 지원하는 브랜치
• release 브랜치는 해당 버전이 완전히 출시 될때까지 존재합니다
• release 브랜치에서는 bug fix할 수 있습니다. 단, 새로운 기능의 개발은 develop 브랜치에서 진행해야 합니다. 즉, 새로운 기능이 개발이 되었다면 다음 Release를 기다려야 합니다.

 

작업흐름은 다음과 같습니다.

1. GIT Repository를 clone할 때, master 브랜치에서 develop라는 브랜치를 즉시 분기 합니다.
2. develop브랜치에서 각각의 기능에 맞는 features 브랜치를 생성합니다.
3. features에 개발된 기능을 테스트 한 후, release 브랜치와 merge 합니다.
4. 새 기능과 관련된 기능들이 development 브랜치에서 개발이 되면, 최종 배포 전에 릴리스 분기로 코드를 분기해야 합니다.
5. release 브랜치 내에서는 오직 bug fix만 커밋을 해야합니다.
6. release 브랜치 내에서 테스트를 진행합니다
7. master 브랜치에 병합한 다음 release번호 태그를 지정합니다
8. release 브랜치에 대한 변경 사항은 개발에 다시 병합되어야 합니다.

$ git checkout master
	Switched to branch 'master'
$ git merge --no-ff release-1.2
	Merge made by recursive.
	(Summary of changes)
$ git tag -a 1.2

$ git checkout develop
  Switched to branch 'develop'
$ git merge --no-ff release-1.2
  Merge made by recursive.
  (Summary of changes)

---

2. Github Flow

Github Flow는 Git Flow와 달리 따로 release라는 단계가 없고 지속적으로 운영에 배포하는 환경에서 유용한 방법입니다. 즉, 새로운 기능이 완성되고 즉시 운영에 배포될 때 사용합니다.

1. 마스터 분기의 모든 것은 배포될 수 있습니다
2. 새로운 작업을 하기 위해서, 작업을 설명하는 새로운 branch를 만들어야 합니다.
3. 로컬 내의 branch에서 commit을 하고, 주기적으로 remote에 있는 같은 이름의 branch로 커밋을 합니다.
4. 만든 branch가 merge할 준비가 되었다고 판단되면 pull request를 합니다.
5. 다른 개발자의 검토를 받고 난 후 master 브랜치와 merge 합니다.
6. master 브랜치와 merge한 즉시, 배포합니다.

*참고

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

https://nvie.com/posts/a-successful-git-branching-model/