프로젝트를 진행하면서 브랜치 전략을 사용해보고 느낀점을 적어보려고 한다.
브랜치 전략?
브랜치 전략은 협업을 하는데 있어서 굉장히 중요한 요소이다.
a라는 사람은 서울에 있고 b라는 사람은 부산에 있다고 해보자
두명은 만나서 협업하기 힘들것이다. 하지만 이 브랜치 전략을 미리 세워 놓는다면
두사람은 별다른 충돌 없이 협업을 할 수 있다.
git flow
안정성을 추구한다면 좋은 선택이 될 수 있다.
협업 인원이 많다면 매우 추천하는 방법이다.
브랜치는 총 다섯개로 운영된다.
- master : 최종 브랜치 이자 배포가 가능한 상태의 작업물
- hotfix : master 브랜치에서 문제가 생겼을 경우 버그를 고치는 브랜치
- release : main에서 올리기전에 버그를 마지막으로 체크하는 브랜치
- develop : 개발 브랜치
- feature : 새로운 기능을 개발하는 브랜치
순서
1. master 브랜치에서 develop 브랜치 생성
2. 작업을 하다가 새로운 기술을 출시해야 한다면 feature 브랜치를 만들어서 작업
2-1. 아주 나중에 나올 기술이 있다면 feature 브랜치를 하나 더 생성
2-2. feature 브랜치에서 작업이 끝나면 develop 브랜치로 머지 후 브랜치 삭제
3. 출시 준비가 되었다면 release 브랜치에서 최종 확인(develop에서는 계속 개발 진행)
4. 준비가 되었다면 main으로 머지
4-1. 만약 출시를 하였는데 버그가 있다면 hotfix 브랜치에서 해결
특징
브랜치가 많기 때문에 다수, 긴 개발에서 용이하다.
또한 배포하기 전에 일련의 과정들로 인해서 더 안전하게 main 브랜치를 보호할 수있지 않나 싶다
개인적인 생각으로는 규모가 적은 프로젝트 에서는 빛좋은 개살구가 아닐까 싶다.
추가로
git flow init으로 확장을 까는 방법이 있다.
git flow feature start라는 명령어로 브랜치를 개설하고
git flow feature finish 라는 명령어로 머지와 브랜치 삭제까지 시켜주는 아주 기특한 확장이다. 만약 팀원들이 이 명령어를 숙지할 의지가 있다면 굉장히 추천한다
github flow
출처 : https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
협업 인원이 적다면 보통 이걸 사용한다
브랜치는 master에서 브랜치 컨벤션으로 인해 정해진 브랜치 이름을 직접 생성한다
사실 너무 간단해서 단점이 있을까 싶지만 만약 에러가 난다면 바로 master에서 fix를 해야하기 때문에 머지에서 코드리뷰가 철저히 들어가야하고
난 사실 규모가 큰 대형 프로젝트 에서는 추천 안할듯 하다.
저번 프로젝트 에선..
팀원들과 의견 조율 중 안정성과 간편함 두개를 모두 잡을 수 없을까 하는 생각이 들었다.
그래서 한번 두개를 융합해봤다
master 브랜치에서 develop 브랜치를 생성하고 develop 브랜치에서 다른 브랜치들을 생성하여 작업했다
develop 브랜치가 git flow 에서 release와 develop 브랜치 두개의 역할을 해주는 것이다.
결론은... 나쁘지 않았다. 만약 팀원들이 간편하지만 안전한 작업을 원한다면 한번 진행해봐도 괜찮지 않을까?
