git branch structure 깃 브랜치 구조

참고 :

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

A successful Git branching model

 

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

 

 

---

위에 원문이고

밑에는 원문보고 설명 정리 해준 블로그

잘되어 있다. 여긴 짧게 정리 하려고 만든 포스트다.

 

이 그림 Git Workflow 라고 함

메인 브랜치는 master, develop ( 항상 유지되는 브랜치 )

서브 브랜치는 feature, release, hotfix ( 일정 기간만 유지되는 브랜치 )

=========================main branch ==========================

master ( == main )

제품 출시용 브랜치 ( 배포 가능한 상태 )

 

develop

서브 브랜치들을 병합하기위한 브랜치( 서브브랜치에서 만든 모든 기능이나 버그가 수정된 것들을 여기서 TEST 한다. )

모든 TEST 를 마치고 배포가능한 상태가 된다면 master 브랜치에 병합(merge)해야함.

그래서 가장많이 쓰이는 브랜치 라고 보면됨. ( 다른사람과 협업하는 공간. )

=========================main branch ==========================

 

=====================sub branch(임시브런치) ======================

feature

기능 개발을 위한 브랜치

새로운 기능개발이나 버그 수정이 필요할 때마다 develop 브랜치로부터 분기해 쓰이는 브랜치

feature 브랜치작업 (협업공간 X, 공유X)은 기능개발하고 완료되면 develop 브랜치에 병합(merge)해서 공유한다,

feature 브랜치는 작업이 다 끝나면 삭제해줘야한다.

 

release

배포를 위한 전용 브랜치

순서 

1. develop 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면 release브랜치를 분기시키고 배포(release)와 직접적으로 관련된 작업을 수행한다.

2, release브랜치에서 배포(release)가능한 상태(추가된 기능 + 모든 기능이 정상적으로 작동)가 되면 master 브랜치에 병합시킨다. + develop에도 추가로 배포

 

 

hotfix

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘master’ 브랜치에서 분기하는 브랜치

특징 : develop 브랜치를 통하지 않고(위험해서) master브랜치에서 직접 분기해서 프로그램 수정후 master에 직접 배포한다. + develop에도 추가로 배포

 

=====================sub branch(임시브런치) ======================

 

브랜치 전체 흐름도

---

본인 결론

 

  + 브랜치 관리
  - master       : 실제 서비스하는 브랜치
  - develop     : TEST 브랜치 내부적으로 사용하는 브랜치
  - feature      : 기능개발 브랜치 ( 추가 개발 또는 개발 수정용 )
  - release      : 배포(DEPLOY)관련 브랜치 ( 깃랩 cicd 또는 문서추가 등 )
  - hotfix        : 급하게 master 브랜치 버그를 고치는 브랜치 ( 예기치 않은 버그 수정요 브랜치 )

 

순서 :

1. master 에서 develop 분기

2. 각각의 개발자가 develop브랜치에서 feature 브랜치로 분기하여 기능 개발, 및 develop브랜치에서 TEST

3. 기능개발이 끝난 develop 브랜치를 release브랜치로 분기하여 배포작업 및 최종TEST 및 버그수정 그리고 문서 추가 후 masetr와 develop에 커밋