브랜치 운영 모델 개선 방안

개선 방안

as-is

현재 master,dev,dev-k,dev-l 총 4개의 브랜치로 운영중이다.

• 통합 브랜치 : master
• 개발 브랜치(develop) : dev
• 토픽 브랜치(feature) : dev-k,dev-l

master는 배포 가능한 버전으로 유지된다.
dev는 각 feature별로 commit되는 통합 테스트 브랜치로 사용되고 있다. 즉, release 브랜치 역할로도 사용된다.
feature 브랜치를 구성하는 방법은 다양하지만, 개발인원 각각 feature 브랜치를 구성하여 개발을 진행한다.
통합 테스트 브랜치에서 수행되는 크고작은 변경사항들은 feature 브랜치에서 진행된다.
feature->dev 단계에서 pull request가 진행된다.
real 배포할 때 tag를 사용하여 릴리즈 관리를 한다.

to-be

release 브랜치는 사용하지 않으며, hotfix 브랜치를 사용할 계획이다.
(아래 정책 참고)

release 브랜치를 사용하지 않는 이유

• profile을 사용하여 빌드한다.
  • 운영 프로젝트는 alpha,beta,real profile 소스코드가 모두 포함된 형태로 구성되어 있다.
  • 즉, release 브랜치건 dev건 동일한 소스코드를 가지는 형태로 구성되어 있다.
• 많지 않은 인원으로 운영되는 점(현재로선 최대 feature 브랜치 2개)
• 복잡해진다.
  ex)릴리즈 브랜치까지 올렸지만, 다시 피처로 돌려 다시 개발하는 상황이 발생하면 develop 브랜치까지 revert해야 한다. 이 때 또 다른 release 브랜치가 존재한다면 생성된 순서에 따라 해당 브랜치까지 영향을 받는다.

`release` 브랜치는 통합 테스트 브랜치이다. 현재 구조에서 `dev`와 `feature`만으로도 기능개발 브랜치와 통합 테스트 브랜치 분리를 명확히 할 수 있다. `develop` 브랜치에서 배포사이클(버그수정,단위 테스트,qa)등을 수행해도 된다. 즉, develop 브랜치가 release 브랜치 롤을 대체해도 무방하다.

각 프로젝트 구성마다 유연하게 전략을 수립할 필요가 있다.

---

release 브랜치 장점

• 배포 환경별 소스코드 분기처리가 되어있지 않은 프로젝트 구성
• (규모가 큰) 프로젝트에서 여러 개의 기능이 동시에 개발된다면, 완료되는 순서대로 릴리즈 하거나, 기능을 소수의 그룹으로 묶어서 릴리즈 관리를 하는등 유용하게 사용될 수 있을 것 같다.
• master는 언제든지 배포할 수 있는 형태를 유지해야 한다.
  • release 브랜치에서 master로 넘어올 때 모든 충돌 이슈를 release에서 해결한다. master에서 코드 충돌을 해결하지 않는다.

hotfix 브랜치 사용 전략

오류의 종류에 따라 사용유무가 갈린다.
1. 단순 오타,주석 실수 등의 간단한 수정은 바로 master 브랜치에서 수정을 진행한다.
2. 긴급한 기능 수정이 필요한 경우, 임시 브랜치인 hotfix 브랜치를 생성하여 작업을 진행한다.

사용 규칙

• <v현재 릴리즈버전>-hotfix-<날짜> 형태로 브랜치 네이밍
  • v1.0.8.1-hotfix-20221123
• Branch protection rules *-hotfix-* 추가
• 분기 순간부터 가장 우선순위에 둔다. 그리고 관련된 작업 외에는 해당 브랜치에서 수행하지 않는다.
• merge는 master 브랜치에서 진행하지 않으며, no-ff 옵션을 사용한다.
• 태그도 release 브랜치와 동일한 방식으로 딴다.
  • v1.0.8.1-hotfix-20221123
• 완료된 브랜치는 삭제한다.

Summary

각자의 프로젝트 구성,목적에 따라서 유연하게 전략을 수립해야 한다.
GitFlow전략을 그대로 사용하든 안하든 시행착오를 겪으면서 각자에게 맞는 브랜치 전략으로 구성하며 발전시켜 나가야 한다.