본문 바로가기

프로그래밍/기타

[Git] Git Branch 관리 전략

반응형

 

 깃으로 협업을 잘 하려면 명령어만 알고 우다다 쓰는게 아니라 브랜치를 어떻게 관리할건지 생각하고 전략을 잘 짜야 합니다. 브랜치 관리 전략에 어떤 상황에서도 사용 가능한 만능 솔루션은 존재하지 않기 때문에, 깃을 사용하는 구성원들이 어떤 상황인지, 프로젝트가 어떻게 구성되는지를 잘 구성하여 브랜치 전략을 세워야 합니다.

 

 

gitflow

5가지의 브랜치가 존재합니다.

1. master(main): 기준이 되는 브랜치로 제품을 배포하는 브랜치

2. develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge

3. feature: 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge

4. release: 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기 위한 브랜치

5. hotfix: master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치

 

- master와 develop이 메인 브랜치고, 나머지는 필요에 의해 운영되는 브랜치

- merge시 항상 -no-ff 옵션을 붙여 branch에 대한 기록이 사라지는 것을 방지하는걸 원칙으로 함

 

 

github-flow

1개의 메인 브랜치인 master브랜치를 기준으로, 필요할 때 마다 브랜치를 생성한 후 master브랜치에 merge하는 형태입니다. 이떄 브랜치의 이름을 통해 의도를 명확하게 드러내는 것이 중요하며 CI/CD가 자연스럽게 이루어 집니다.

 

gitlab-flow

gitflow와 github-flow의 중간정도의 느낌의로, master, feature, production 3가지 브랜치를 이용한다.

 

- feature: 작업을 진행하는 브랜치

- master: feature 브랜치에서 병합된 기능을 테스트하는 브린치. gitflow의 develop과 같다.

- production: 배포 브랜치

 

아래 링크에서 GitLab Flow를 유지하기 위한 팁을 확인할 수 있다.

 

https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/

 

 

반응형