squash의 사용은 보류하기로 했습니다. 지금 상황에서는, 가장 기본적인 merge만을 진행하는 것이 이루고자 하는 목적에 거의 부합하므로, squash 사용 시점은 차근차근 살펴보도록 하겠습니다. (보류 이유: 그래프를 읽을 수가 없음. 그렇지만 커밋 메시지를 깔끔하게 정리하기 위한 해결책이 필요함)

서비스개발파트의 프론트엔드에서는 현재 monorepo를 채택하고 있으며, 여러 프로젝트가 같이 관리됨에 따라 뭘 배포해야될지 헷갈리는 혼선을 방지하고자 모든 프로젝트가 main 브랜치로부터 바로 파생되는 Trunk-based development 방식을 채택하고 있습니다. 이에따라, develop 브랜치를 가지고 있지 않으며 feature/{프로젝트명}/main 브랜치가 사실상 develop 브랜치의 역할을 하고 있습니다(develop이 여러개로 분리되었다고 보시면 됩니다.)

콴다 프론트엔드 팀의 방식을 채택했습니다. 브랜치명이 바로 feature로 분기되는 이유는, CI/CD 파이프라인을 구축함에 있어 여러 프로젝트가 효율적으로 구분될 수 있는 구분자로써의 역할을 할 수 있기 때문입니다.

선행작업

fast-forward merge 를 끄도록 합니다.

git config --global --add merge.ff false

목적

• 그래프가 적절히 분기된 모습을 한 눈에 볼 수 있어야 한다.
• 배포 시점을 정확히 찾아낼줄 알아야 한다

이 모든 목적을 일단은 no-ff merge 가 해결해줌

브랜치의 목적

• main: 프로덕션서버에 연결되며, 한 눈에 버전이 모두 보이도록 최종 배포 커밋, hotfix 커밋 관한 사항만 보관되어야 합니다.
  • 브랜치 그래프가 정리되지 않은 이슈로 최종 배포, hotfix 커밋만 보관하도록 하지 못했습니다.
• feature/{프로젝트명}/main: 개발서버에 연결되며, 기능개발에 관한 모든 커밋이 들어가 있어야 됩니다.
• hotfix: main에서 발생하는 버그를, 배포되지 않은 상태에서 픽스하기 위한 임시 브랜치입니다.
• feature/{프로젝트명}/{!main}: 개발서버 배포되기 전 기능개발을 자유로이 하기위한 브랜치입니다. feature/{프로젝트명}/{main}으로부터 파생됩니다.

브랜치 간 병합 방법