일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- bounds이해
- lazy 사용
- lifecycle
- Your app is missing support for the following URL schemes: your_ios_client_id
- Explict Identity
- Lifetime of SwiftUI
- Structural Identity
- Xcode
- Identity
- Demystify SwiftUI
- swift
- ios
- spring guide
- WWDC21
- git
- java
- github
- ios login
- xml delegate
- lazy 위험성
- native개발
- schemes
- consuming a restful web service
- Spring
- sementic versioning
- view
- 적절한 사용방법
- developer
- Lazy
- 보라색오류
- Today
- Total
Dev_Dylan
[Git] 좀 더 전략적으로 브랜치 관리하기 [Git Branch Strategy] 본문
간단한 토이프로젝트를 진행하려고 했는데,
어차피 앞으로 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)
'Git' 카테고리의 다른 글
[Backend] 개발초기, env(환경변수)관리를 더 쉽게해볼 수 없을까? (2) | 2025.07.07 |
---|