
지금껏 git branch의 전략으로 main, dev, feat만을 사용해왔으나,
개발 및 협업을 진행해오며 hotfix, chore 등 기타 브랜치 전략 도입의 필요성을 체감하는 중이에요.
해당 브랜치들을 원격 레포상에 추가했고, 어느정도 사용방법에 대한 고민과 적용을 해본 후 용이함을 체감해 아래와 같이 함께 사용해주시면 어떠싶사 제안 드려요!

저번에 말씀드렸다시피, CI/CD의 이벤트 트리거인 main으로의 PR Closed & Merge 조건 때문에,
아주 사소하거나 급한 수정사항 때문에 PR로그가 너무 지저분해지는것이 아닌가 함께 고민해보았는데요
PR을 안거치고 merge 룰만으로 CI/CD를 발동시키는것은 주요한 수정내역을 명시적으로 기록하여 공유하기 어려울 것이라는 생각이 들어서 hotfix 브랜치를 사용하는 것을 제안합니다!
해당 브랜치는 주요한 개발 변경점을 dev를 통해 main(배포수준)에 반영한 이후, 에러, 버그 수정 등 급하거나 사소하게 수정 및 제품에 반영해야 할 내용들을, hotfix(from main)을 통해 수정 및 main에 dev를 거치지 않고 (하지만 PR을 통해 merge되어야 합니다!) 직접 반영하는 브랜치에요!
비록 PR에는 여전히 많은 것들이 들어오겠지만, hotfix를 사용함에 따라, 중요한 변경점은 dev를 통해, 다소간 중요도가 적은 변경점은 hotfix를 통해 들어왔음을 명시할 수 있기 때문에 PR내역 기록 및 확인에 도움이 될 것이라고 확신합니다.
env파일 사용 및 주입에 대한 수정을 수행하며, 예전부터 해왔던 작은 의문점에 다시금 불씨가 붙었슴다.
feat은 기능 개발에 관련한 branch 일텐데.. 과연 이런 기능에 미치지 않는 low level의 작업을 feat으로 사용하는게 맞나?
그래서 찾아봤고, chore 브랜치를 알게 됐습니다.
chore란? 빌드 업무 수정, 패키지 매니저 수정 등에 관한 변경점 반영하는 브랜치이다!
해당 브랜치 또한 도입하여 기능 개발과, 기타 환경설정에 대한 작업을 확실히 분리해주는것이 좋겠습니다!
chore 브랜치는 from dev, to dev 로 사용하면 될 것 같습니다! 즉, dev브랜치로부터 업데이트받고, dev브랜치로 넣어주어 dev를 main과 직접 소통할 일은 없습니다.
dev <-> feat
dev <-> chore
main <-> (by PR) dev
main <-> (by PR) hotfix
dev <- hotfix
여기서 주목해 보아야 할 것이 있다. hotfix만 유일하게 dev를 거치지 않고 main에 merge되는데 이것에 대한 추가적인 의문과 고민이 있다.
지금까지는 반드시 모든 branch가 dev를 거쳐 main에 병합(수렴)되었으나, hotfix는 유일하게 dev에 먼저 반영되지 않은 채 main으로 선반영 된다. 이에 따라, hotfix <-> dev간 commits 확산을 수행해주어야 하는데, 이런 확산 방법에 대한 공부가 필요해보인다.
자동으로, 규칙적으로, 필수적으로 확산시킬 수 있다면 좋겠으나, 내 부족한 지식선에서는 이것을 컨벤션으로 해결하여 각 개발자의 영역으로 남겨놓는것이 일반적이라고 알고 있어서 어떤 방식을 사용해야할 지 추가 고민이 필요하다.