개인 프로젝트라 복잡한 브랜치 전략은 필요하지 않았지만, 연습 겸 Git-flow 전략을 참고해서 버전관리를 했다.
지금까지 63개의 커밋을 하면서, 아무리 함께 하는 팀원들이 있다고 생각해도 release 브랜치가 정말 필요한 것인지 의문이 들었고 브랜치 전략이 너무 복잡하다는 생각이 들었다. 🤔
그러다 며칠 전 Github-flow에 대해 알게 되었는데, 두 전략을 비교해서 보니 의문이 풀렸다. 내 프로젝트에 Git-flow는 과했던게 맞았다.
Git-flow vs. Github-flow
두 개를 간단히 비교해 메모해 둔다.
가장 큰 차이는 release 브랜치인 것 같다. Git-flow는 release 브랜치를 통해 배포 전 충분한 테스트가 가능하기 때문에, 금융권과 같이 탄탄한 프로덕션이 요구되는 프로젝트에 적합하다. 단, 브랜치 관리에 대한 비용이 크다는 것이 최대 단점이다.
반면 Github-flow는 단순한 브랜치 전략으로 빠른 개발 및 배포에 유리하다. 버그에 대한 리스크가 크지 않은 소규모 프로젝트에 적합하다.
즉 내 프로젝트에는 Github-flow가 딱이다.
Git-flow
main, develop, feature, realese, hotfix 다섯 가지의 브랜치를 사용한다.
develop: 개발이 진행되는 브랜치.feature: 기능 개발을 위해develop에서 분기한 브랜치.main: 현재 배포 중인 코드를 갖는 브랜치.release: 다음 버전을 위한 개발이 완료되면develop에서 분기한다. 배포를 위한 준비가 완료되면main과develop으로 병합한다.hotfix: 긴급한 버그 수정이 필요할 때main브랜치에서 분기하고 작업이 완료되면main으로 바로 병합한다.
병행 운영되는 여러 개의 버전을 관리하기 좋다. 릴리즈 버전이 따로 관리되기 때문에 현재 버전과 다음 버전 작업을 이동할 수 있어서 프로젝트 규모가 크고 팀원이 많을 때 좋다.
예를 들면 QA 팀에서 이번 release를 테스트 하면서, 동시에 개발팀은 다음 release를 위한 개발이 가능하다. 만약 테스트 중 버그가 발견됐다면 이번 release 브랜치에서 수정을 하고 다시 다음 버전을 위한 release 브랜치로 돌아갈 수 있는 것이다.
🔗 우아한 기술블로그의 글에서도 Git-flow를 채택한 이유로 위와 같은 상황을 들고 있다. 팀원이 늘어나면서 모두가 이번 버전을 위한 기능을 개발하는 것이 비효율적이기 때문에, 이번 버전 개발과 다음 버전 개발을 병렬로 진행할 필요가 있었기 때문이라고 설명하고 있다.
단점으로는 브랜치 전략이 복잡하다는 것이다. 특히 release 브랜치를 관리하기 위한 기술 부채가 생길 수 있다.
Github-flow
Github에서 사용하는 전략이라 이러한 이름이 붙었다고 한다. 꼭 Github을 사용할 필요는 없다. Github-flow는 심플하게 2개의 브랜치를 사용한다.
main: Git-flow의main브랜치와 동일하다.feature: 새로운 기능 개발을 위해main브랜치에서 직접 분기한다. 작업이 완료되면main에 바로 병합한다.
Github-flow는 release 브랜치 개념이 없으며, hotfix 브랜치도 feature 브랜치가 대신한다.
지속적이고 빠른 배포에 적합하며, 기능 개발이 완료된 후 featue 브랜치를 병합하는 일 외에는 브랜치 관리가 거의 필요하지 않다.
단, 개발이 완료된 사항은 즉시 프로덕션 코드에 반영되므로 버그에 주의해야 한다.
