Gitflow

  • 이름 때문에 표준(?) 느낌이 있지만, Git을 활용한 워크플로중 하나의 아이디어일 뿐이다.

  • 기본적으로 두 개의 브랜치에서 작업이 이뤄진다. main, develop

    • 즉, 두 개의 브랜치에서 해당 프로젝트의 작업 이력을 관리/기록한다.

  • main 브랜치는 공식적인 릴리즈 이력을 저장한다.

    • 보통 main 브랜치내 커밋에 버전 번호로 태그를 지정하여 버전 관리를 한다.

  • 첫 develop 브랜치는 main 브랜치에서 만들어진다.

    git branch develop
git push -u origin develop

  • develop 브랜치는 프로젝트의 전체 이력이 포함되는 반면, main 브랜치에는 요약된 버전이 포함된다.

  • 모든 개발자들은 centeral(remote) repository를 등록하고, develop 브랜치의 추적 브랜치(tracking branch)를 만들어야 한다.

Feature branches

  • 새로운 기능 개발이 필요할 경우 백업/협업을 위해 별도 브랜치가 있어야 한다.

  • 기능 개발을 위한 별도 브랜치(feature 브랜치)는 최신 develop 브랜치에서 생성한다. ( main 브랜치 X)

    git checkout develop
git checkout -b feature/add-user-service # before git 2.23
git switch -c feature/add-user-service # after git 2.23

  • 기능 개발이 완료되면 develop 브랜치로 다시 merge 한다. feature 브랜치는 main 브랜치와 직접적인 상호작용해서는 안된다.

    Note

    병합(merge) 되는 방법은 다양하다. 혼자서 개발하는 프로젝트라면 로컬에서 git merge 명령어를 통해 병합할 수도 있다. 많은 개발자들간에 협업 혹은 코드리뷰나 CI 결과를 통해 병합을 제어한다면 GitHub의 Pull Request를 활용할 수 있다.

Release branches

eNpLzyxxL0osyOBSAILk NzczBIkpkJJYrqVUpmhnoGegRJYPKkoMS85QyEltSw1J78Auy5khUWpOamJxan6QDOApmCoz0hNzs4vLcFpHkyeSGNyEzPzwCK5qUXpqWi64J4xhHkGq XYtGL3JwCvwl1D

mermaid source code 
gitGraph
    commit
    commit tag:"v1.0.0"
    branch develop
    commit
    commit
    branch release/v1.1.0
    commit
    checkout develop
    commit
    checkout release/v1.1.0
    commit
    checkout main
    merge release/v1.1.0 tag:"v1.1.0"
    checkout develop
    merge release/v1.1.0
    commit
    commit

  • 릴리즈 날짜가 다가오거나 릴리즈를 위한 기능이 충족되면 develop 브랜치에서 release 브랜치를 분기한다. (main 브랜치 X)

    git checkout develop
git switch -c release/v0.1.0
    Note
    릴리즈 조건

    위에 적혀있듯이 “릴리즈 날짜가 다가오거나 릴리즈를 위한 기능이 충족되면”이 릴리즈 브랜치가 생성되는 조건이다. develop은 언제든 prodction에 배포되는 브랜치가 아니며, 릴리즈가 준비되면 함께 해당 릴리즈 버전에 배포되어야 할 작업이 머지되어야 한다.

    main 브랜치만 관리하고, 이 브랜치가 어느 때든 배포가 가능한 브랜치 전략은 GitHub flow를 참고하길 바란다.
    Note
    Trunk-Based Development, TBD

    소규모 팀을 위한 개발 방법론으로, 모든 개발자가 트렁크(trunk or main)라는 단일 브랜치에서 직접 모든 작업을 하는 것이다. 다만 몇가지 규칙이 있다. * Pair or Mob Programming - 짝을 이뤄서 혹은 전체 팀이 동일한 컴퓨터에서 함께 작업을 수행하는 개발 방식이다. * 코드 베이스가 항상 릴리즈 가능한 상태임을 확신해야 한다. 그러기 위해 자동 테스트가 실행되어야 하며, 효과적이고 우수한 테스트 전략이 필요하다. * 소규모 배치로 작업한다. 작업 단위를 며칠이 아닌 몇시간 안에 완료할 수 있는 소규모 변경사항으로 쪼갠다. * 빠른 빌드 속도가 필요하다. 이 것이 안된다면 시스템 아키텍터 개선이 필요하다는 것을 의미한다. * main에 완료되지 않은 코드가 있을 수 있다. 간단한 것은 Branch by Abstaction 방식으로, 복잡한 태스크의 경우엔 Feature Flags 방식을 사용할 수 있다.

    TBD vs. GitHub flow

    TODO

    참고

  • release 브랜치가 생성되면 다음 릴리즈 주기가 시작된다.

    • release 브랜치는 버그 수정, 문서 생성, 해당 릴리즈에 포커싱된 작업만이 포함된다.

    • develop 브랜치를 다음 릴리즈를 준비할 수 있으며, 이 시기부터 다음 릴리즈를 위한 feature 브랜치를 병합할 수 있다.

  • 해당 릴리즈가 출시될 준비가 되면 release 브랜치를 main 브랜치에 병합하고, 버전 번호로 태그를 생성한다.

    git switch main
git merge release/v0.1.0
git tag v0.1.0
git push origin v0.1.0

    • 또한, 릴리즈가 시작된 이후에 추가되었을 수 있는 작업들을 위해 develop 브랜치에도 병합(back merge)한다.

      git switch develop
git merge release/v0.1.0

    • 두 브랜치에 병합이 완료된 release 브랜치를 제거한다.

      git branch -D release/v0.1.0

Hotfix branches

  • hotfix 브랜치는 유지보수 및 긴급 대응을 위해 프로덕션 릴리즈를 빠르게 패치하기 위해 사용된다.

    • 버그 수정을 위한 전담 브랜치가 있으면 나머지 워크플로를 중단하거나 릴리즈 주기에 영향을 주지 않고도 문제를 해결할 수 있다.

  • hotfix 브랜치는 main 브랜치를 기반으로 생성되는 것을 제외하고는 release 브랜치와 유사하다.

    • main 브랜치에서 분기되는 유일한 브랜치다.

      git switch main
git switch -c hotfix/bugfix-branch

  • 기능 수정이 완료되는 즉시 main, develop 브랜치에 병합되어야 한다. 이 후, main 브랜치에서 업데이트된 버전으로 태그를 생성해야 한다.

    git switch main
git merge hotfix/bugfix-branch
git tab v0.1.1
git push origin v0.1.1
git switch develop
git merge hotfix/bugfix-branch
git branch -D hotfix/bugfix-branch
    Warning
    (예외) RB가 존재할 경우 어디에 back merge를 할까?

    RB가 이미 있을 경우 hotfix 는 develop 브랜치가 아닌 RB에 merge한다. (참고)

    RB가 병합될 때 develop 브랜치에도 함께 반영되고, bugfix 된 RB를 배포시에도 포함할 수 있기 때문이다.

    커밋 로그가 복잡하지 않다면 hotfix 백머지된 이후에 다시 RB를 다시 생성하고 cherry-pick 하는 것도 방안일 수 있다.
Note
develop에 이미 반영된 commit을 hotfix로 배포하고자 할 떄 어떻게 해야하는가?
gitGraph
    commit
    commit tag:"v1.0.0"
    branch develop
    commit
    commit id:"bug-patch1"
    commit id:"bug-patch2"
    commit
    checkout main
    branch hotfix/v1.0.1
    cherry-pick id:"bug-patch1"
    cherry-pick id:"bug-patch2"
    checkout main
    merge hotfix/v1.0.1 tag:"v1.0.1"
    checkout develop
    merge hotfix/v1.0.1
    commit

Support branches

References