브랜치 전략

토이 프로젝트 진행시 이전까지는 혼자서 작업하기 때문에 main브랜치에서 feature를 생성해서 작업하거나 main브랜치에서 작업하는 일이 많았다. CI/CD가 구축되면서 main브랜치에 코드가 병합되면 배포가 바로 실행된다. 불필요한 배포가 자꾸 발생하여 브랜치 전략을 수립하고 진행하려고 한다.

---

Git Flow

• main (또는 master): 배포 가능한 안정된 코드만 존재
• develop: 다음 릴리스를 위한 통합 개발 브랜치
• feature: 새로운 기능 개발을 위한 브랜치 (feature/login, feature/search 등)
• release: 배포 준비를 위한 브랜치
• hotfix: 배포 중 문제가 생겼을 때 긴급 수정용 브랜치

---

GitHub Flow

GitHub에서 권장하는 단순한 브랜치 전략

• main: 항상 배포 가능한 상태를 유지
• feature: 기능 단위로 생성되며, 작업이 끝나면 Pull Request를 통해 main에 병합

---

GitLab Flow

Git Flow와 GitHub Flow의 장점을 결합한 전략

• main: 배포용 브랜치
• develop or staging: 테스트 환경
• 기능 단위 브랜치(feature, bugfix, 등)

---

이전 직장에서 작업할때는 Git Flow전략으로 진행했었다. 다소 복잡하다는 단점이 있지만 업무를 나누고, 운영 상황에서 문제 발생시 hotfix 브랜치는 필수적이였다. 하지만 지금 혼자 작업하는 내 프로젝트에서는 다소 과한 전략이라고 판단했다.

 

GitHub Flow는 기능 개발시 main브랜치에 바로 병합해야한다는 단점이 있다. 해당 전략은 지금도 하고있는 전략이다. 즉각적인 배포가 필요 없고, 즉각적인 배포에 문제가 없기 위해서는 api에 버저닝이 필요한데 이 또한 오버헤드가 발생하여 지금 상황에 맞지 않는다.

 

결론적으로 GitLab Flow전략을 사용하여 main브랜치로부터 develop브랜치를 생성 후 배포 상황이 발생하면 main브랜치로 병합하여 배포하는 전략으로 진행하려고 한다.