Git Flow
기존에 대회를 진행할 때에는, 항시 유지하는 브랜치로는 main이 있었으며, 일정 기간 동안만 유지되는 브랜치로는 feat과 test 등이 있었습니다.
대회에서는 작업한 내용을 배포하지 않았기 때문에 이러한 브랜치 전략을 이용하는 데에 큰 문제가 없었습니다.
그러나, 배포를 진행해야하는 최종 프로젝트를 진행하게 됨으로서, 이러한 형식의 브랜치 전략에는 몇가지 문제점이 있었습니다.
- main 브랜치가 배포되게 됨으로서, 작업한 내용들에 대한 검수가 이루어지기 전에 배포판에 반영이 되어 배포판에 심각한 버그가 발생 수 있습니다.
- 배포 버전에 반영할 필요가 없는 실험적인 기능의 추가나 여러 실험 사항들 또한 자동으로 배포가 되는 문제가 발생할 수 있습니다.
- 배포 버전에서 버그를 수정하고 프로젝트 검수를 진행해야 하기에 배포 버전의 관리 측면에 어려움이 발생할 수 있습니다.
이에 따라, 개발 프로젝트에 맞는 Branch 전략을 새로 설정하기로 하였고, 이에 맞는 Git Flow를 사용하기로 하였습니다.
실제 개발 과정에서, 프로토타입이 제작되기 전에는 dev 브랜치 없이 main 브랜치만 운용을 했었는데,
일부 코드가 merge되는 과정에서 main 브랜치에 에러가 발생하게 되었고, 해당 에러가 수정되는 과정 동안 main 브랜치를 이용한 배포 과정에서 어려움을 겪게 되었습니다.
비록 지금은 개발 단계여서 큰 문제는 없었지만, 실제 서비스가 되고 있었을 경우에는 서비스가 중단되는 매우 큰 문제를 야기할 수 있게 되므로,
dev 브랜치를 운용하는 전략이 필요하다고 생각했습니다.
Git Flow를 바탕으로, 이번 프로젝트에서 사용할 Branch 전략을 설정하였습니다.
- 항상 유지되는 메인 브랜치
- main: 실제 배포가 되는 브랜치입니다.
- dev: 다음 출시 버전을 개발하는 브랜치입니다.
- 일정 기간동안만 유지되는 보조 브랜치
- feat: 기능을 개발하는 브랜치입니다.
- release: 이번 버전 출시를 준비하는 브랜치입니다. main에 배포 전, 버전을 점검합니다.
- hotfix: 배포판에 발생한 긴급한 버그를 수정하는 브랜치입니다.
- 기능 개발은 feat 브랜치에서 진행합니다.
- 어느 정도 기능 개발이 진행되면, dev 브랜치에 pull request를 날립니다.
- dev 브랜치에 merge가 되면, feat 브랜치는 삭제합니다.
- 새로운 기능 개발 시, 다시 feat 브랜치를 생성하여 진행합니다.
- 새로운 버전을 출시할 정도로 개발이 완료되면, dev 브랜치에서 release 브랜치를 분기합니다.
- 새로운 버전에 문제점이나 버그가 없는지를 release 브랜치에서 점검하고 수정합니다.
- 문제 해결이 완료되면, main 브랜치로 병합하여 새로운 버전을 배포합니다.
- 배포중인 main 브랜치에서 버그가 발생할 경우, hotfix 브랜치를 만들어서 긴급 수정을 합니다.
Branch 전략을 적용한 Team RAYN의 나만의집 프로젝트의 Git Graph는 다음과 같습니다!
