브랜치 전략

자동 배포를 구현할 때 크게 관여하는 것이 분기 전략입니다.
여기를 확실히 짜주면, 운용은 편해지고, 적당하게 하면 괴로운 생각을 합니다.
거기서 이번은 자신이 짜 봐, 하기 쉬웠던 브랜치 전략의 예를 소개하고 싶습니다.
그런 방법이 있다면 의견을 부탁드립니다

브랜치 전략에 관해서는 아래의 기사 등이 매우 참고가 됩니다.
Git 브랜치 전략의 이것
GitHub Flow
Git의 브랜치 전략
GitHub flow 또는 Git flow는 분기 전략에 대해 이해하지 못했습니다.

애용하는 분기 전략

결론, 브랜치는 master , feature 브랜치의 2개만으로 운용합니다.
전략으로 말하면 github-flow에 해당합니다.
그리고 github 태그를 사용하는 것이 매우 편리하다고 생각합니다.

어떻게 개발 흐름인가?

개발자가 기능 구현

다른 개발자가 approve하고 master 분기에 병합

스테이징 환경에 자동 배포

스테이징 환경에서 테스트에 문제가 없으면 github 태그를 master 브랜치에 부여

프로덕션 환경에서 자동 배포

CircleCI에서는 아래와 같이 정의할 수 있다고 생각하고, "release-v"로 시작하는 태그를 부여하면 배포가 시작되도록 구현할 수 있습니다.

- deploy_prod:
   filters:
     tags:
       only: /^release-v.*/
     branches:
       ignore: /.*/

왜 애용하는가?

간단하기 때문입니다.
간단하면 다음과 같은 이점을 얻을 수 있습니다.

학습 비용이 낮음

새롭게 엔지니어가 들어갔을 때도, 신졸 엔지니어가 들어갔을 때도 git-flow와 비교하면 꽤 학습 코스트를 억제할 수 있다고 생각합니다.

혼란하기 힘들다

git-flow와 같이 develop , master , release 브랜치 등 많은 브랜치가 있는 것은 매우 기쁩니다. 잘못해서 master 에서 브런치 끊었다든가, develop 브랜치에서 끊지 않으면, hotfixes 브랜치 끊지 않으면 생각하는 것이 번거롭게 되어 버려, 인위적 실수에도 연결됩니다.

불편함이 없어?

지금은 없습니다.
작은 제품을 운용하고 있으므로, 이 flow로 전혀 돌려 갈 수 있고, 곤란한 일이 없습니다.

다음에 무엇을 시도?

GitLab-flow를 사용해보고 싶습니다.
Github-flow에 가깝고 실무에서 사용한 적이 없습니다.
Git-flow는 사용하고, 엉망이었기 때문에, 많이 사용하고 싶지 않습니다 w