Dev_Dylan

[Git] 좀 더 전략적으로 브랜치 관리하기 [Git Branch Strategy] 본문

Git

[Git] 좀 더 전략적으로 브랜치 관리하기 [Git Branch Strategy]

Dylan_21 2023. 12. 13. 03:56

간단한 토이프로젝트를 진행하려고 했는데,
어차피 앞으로 Git으로 버전 관리를 할 것이기 때문에
좀 더 체계적으로 git 관리를 하려고 한다.

 

간단하게 github을 통해 5가지 사용하는 방법

참고만....

https://github.com/Dylan-yoon/GitBranchStrategy/tree/master

Git Branch Strategy

뜻 그대로 깃 브랜치 전략이다.
간단하게 브랜치를 효율적으로 관리해서 출시부터 개발까지 관리하기 편하게 하는 것이다.
자주 보이는 Git Branch Strategy 이미지를 간단하게 들여다봤다.

이 그림이 제일 잘 표현되어서 많은 블로그 및 글에서 주로 사용되었다.

5가지의 전략적 Branch

5개의 부류로 나누어진다

  • master (github 기본설정은 main이지만 취향이라고 생각)
    • 영구적인 브랜치
    • 제품 출시될 수 있는 브랜치
    • (생성하지 않음 유일)
  • hotfix
    • 출시 버전에서 발생된 버그 수정 브랜치
    • 출시된 제품에서 버그가 발생하면 master로부터 hotfix 브랜치를 만든다.
    • 수정이 완료되면
      • develop에 Merge
      • master에 Merge
  • release
    • 출시 버전을 준비하는 브랜치
    • develop 브랜치에서 릴리즈 될 브랜치
  • develop
    • 영구적인 브랜치
    • 다음 출시 버전 개발하는 브랜치
    • master에서 브랜치를 만든다.
  • feature
    • 기능 개발 브랜치
    • Develop에서 브랜치를 만든다.
    • 구현이 완료되면 다시 develop에 Merge 한다.

master, develop 브랜치는 Main Branch이며 단 하나만 가지고 있다.
이를 보조해 주는 것이 hotfix, feature, release
master에서는 hotfix가 파생된다.
develop에서는 feature, release가 파생된다.

Feature

전체적인 Feature의 생명을 터미널 명령어를 통해 알아보자!

  • somefeature를 develop 브랜치에서 가져온다
    (feature 브랜치 생성)
    • $ git checkout -b somefeature develop
  • develop 브랜치로 Switch
    • $ git checkout develop
  • somefeature를 develop에 머지
    • $ git merge --no-ff somefeature
    • --no-ff 사용 이유 : 커밋을 남기기 위해
      • no fast forward
      • git merge를 하게 되면 somefeature에 대한 정보가 없고 브랜치를 somefeature브랜치를 삭제하면 어떠한 기록도 남지 않기 때문
    • $ git branch -d myfeature
      • --no-ff를 사용함으로써 더 이상 브랜치가 필요 없기 때문에 삭제
    • $ git push origin develop
      • remote에 push

Release

release 브랜치에서는 버전 번호, 빌드 날짜 등 여러 메타데이터들을 준비하고, 사소한 버그 수정이 가능하다.
release 브랜치를 생성할 때 버전 번호를 할당하면서 시작된다.
release 브랜치는 출시를 완전히 하고, 다음 release가 생성될 때까지 존재해도 된다.

release 브랜치 또한 전체적인 생명을 Terminal을 통해 알아보자

생성

  • $ git checkout -b release-1.0 develop
    • develop으로부터 브랜치를 생성해 준다. (버전 포함)
  • 파일 내부에서 버전 관리
  • $ git commit -a -m "Bumped version number to 1.0"

종료

master, develop에 merge

  • $ git checkout master
    • master브랜치 변경 후
  • $ git merge --no-ff release-1.0
    • feature와 같이 merge후 삭제해도 기록을 남기기 위해 --no-ff를 사용해 merge
  • $ git tag -a 1.0
    • feature와 달리 tag를 달아준다.
  • 출시하면 된다.

또한 다른 개발을 위해 develop에 release의 변경사항을 merge 해준다.

  • $ git checkout develop
  • $ git merge --no-ff release-1.0
  • 반복으로 설명 생략

당연히 develop을 통해 다른 개발이 시작되면 충돌이 날 수밖에 없다.
여기서 잘 해결하고 merge해 준다!

삭제

  • $ git branch -d release-1.0
  • 역시 생략

Hotfix

위 2가지 Feature, Release branch를 이해했다면 쉽게 이해할 수 있다.
먼저 hotfix는 master에 예상치 못한 충돌 및 버그들이 발생했을 때, 즉각적으로 조치해서 배포해야 할 때 사용한다고 생각하면 된다.
release와 마찬가지지만 hotfix를 사용하는 동안 다른 추가적인 작업을 계속 진행할 수 있다.

또한, Terminal 명령어로 이해해 보자
3.4.2 버전 배포를 진행했다고 가정하자, 여기서 버그가 발생했을 때, hotfix를 사용해 보자.

생성

  • $ git checkout -b hotfix-3.4.3 master
    • master로부터, 그다음 버전으로 hotfix를 생성한다.
  • 파일 내부에서 버전 관리
  • $ git commit -a -m "Bumped version number to 3.4.3"
  • $ git commit -m "Fix: Problems"
    • 버그에 대한 하나 이상의 커밋을 남긴다.

삭제

위 과정과 같다

  • $ git checkout master
  • $ git merge --no-ff hotfix-3.4.3
  • $ git tag -a 3.4.3
  • $ git checkout develop
  • $ git merge --no-ff hotfix-3.4.3
  • $ git branch -d hotfix-1.2.1

만약 release 가 진행 중이면 release 브랜치에도 똑같이 merge 해주어야 한다.

hotfix 주의사항

  • 버전이 겹칠 수 있으니 꼭 신경 써야 함.
  • release가 진행 중인지 확인해야 함.

언제나

  • merge 할 땐 항상 충돌 주의

Ref.

우아한 기술블로그

https://techblog.woowahan.com/2553/

Gitkraken

https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy

Gitflow workflow

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

A successful Git branching model (ENG)

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

Comments