Git을 이용한 협업 및 브랜치 전략
이번에 군 SW 해커톤에 참여하면서 WILIM이라는 프로젝트를 시작하게 되었다. 처음부터 함께 하기로 했던 친구 한 명과, 추후에 팀 빌딩 과정에서 감사하게도 우리 팀에 지원해주신 두 분을 포함한 전체 4명으로 개발이 시작되었다.
나는 지금까지 개인 프로젝트만 진행하였고 팀 단위로 협업을 진행한 것은 처음이었기에 git을 활용한 협업을 경험해보기 좋은 기회였다. 그래서 git flow 등 대표적인 브랜치 전략이나 좋은 코드리뷰에 대한 고찰들도 여럿 찾아보았다.
보통 git flow라고 하면 서비스를 배포하는 master 브랜치, 기능을 개발하는 develop 브랜치, 세부 기능들을 개발하는 feature/XXX 브랜치, QA를 진행하는 release 브랜치, 긴급 오류를 수정하여 반영하는 hotfix 브랜치를 기본으로 둔다. 그러나 우리는 QA를 진행할 정도의 프로젝트가 아니라고 생각했고, 지속적인 개발이 예정된 것이 아닌 단발성 프로젝트에 가까우므로 이를 단순화한 브랜치 전략이 필요하다고 생각했다.
그래서 기본적인 배포를 진행하는 master 브랜치를 기반으로, 프론트엔드의 코드를 개발하고 저장해두는 feature/Frontend, 백엔드의 코드를 개발하고 저장해두는 feature/Backend를 하위 브랜치로 두어 개발하였다. 각 개발자들은 upstream에 있는 레포지토리를 fork하고, fork한 브랜치 내 자신의 역할에 해당하는 브랜치로 이동 후 개발을 진행하도록 하였다.
여기서 가장 걱정되었던 conflict 문제는 다음과 같이 해결하기로 하였다.
-
해커톤을 주최하는 국방오픈소스아카데미에서는
WEB(FE),WEB(BE)와 같이 프론트엔드 소스 저장용 파일, 백엔드 소스 저장용 폴더을 따로 두어 레포지토리를 관리하라고 하였기 때문에,feature/Frontend브랜치에서는WEB(FE)폴더만,feature/Backend에서는WEB(BE)폴더만 두고 개발할 수 있도록 했다. 그러면 프론트엔드 브랜치에는 백엔드 폴더가 없고, 백엔드 브랜치에는 프론트엔드 폴더가 없으므로master브랜치로merge를 진행하여도 서로 충돌이 발생할 일이 없다. 각자의 코드에 간섭할 수 없기 때문이다. -
그리고, 각 분야의 개발자들을 개발을 시작하기 전에 꼭
git pull upstreamfeature/XXX와 같은 명령어로upstream브랜치에 있는 최신 코드를 받아올 수 있도록 하였다. 이러한 사전 작업들 덕분에 현재까지 큰 충돌 없이 개발을 진행할 수 있었다.
각자 개발자들이 개발을 진행한 뒤에 origin branch에 push를 진행하면 origin -> upstream으로 pull request를 생성할 수 있고, 생성된 PR은 각 분야 별 담당자가 코드를 간단히 리뷰한 뒤 merge를 수행할 수 있도록 했다.
추가적인 문제에 대한 고민과 해결
Frontend -> master로 PR을 날리고 master 브랜치에 변경사항이 반영되면, github 관점에서는 master -> Backend에도 변경점을 반영할 수 있도록 해준다. 그러나 이러한 과정을 거치면 Backend에서도 프론트엔드 코드가 생성이 되어 merge하는 경우에 conflict를 유발하기 쉽고, 모든 브랜치에 반영되는 merge 사항들에 대해 PR을 2번씩 추가로 진행해줘야한다는 번거로운 일이 발생했다. 이렇게 PR 지옥에 하루 정도 빠지고 나니, 코드 관리를 위해 규칙을 정하는 것이 필요하겠다고 생각했다.
그렇게 나 나름대로 두 가지의 규칙이 생겼는데, 다음과 같다.
1. master 브랜치에서 하위 브랜치로는 PR을 진행하지 않는다. 무조건 하위 -> 상위 브랜치로만 PR을 진행한다.
2. master 브랜치는 추후 CI/CD 파이프라인을 구축할 예정이므로, 팀원들과의 충분한 논의를 거쳐 merge를 진행한다.
즉 feature/XXX 각 브랜치들은 맡은 분야에 대한 최신 코드만을 저장하고, master로의 merge는 중요한 기능의 업데이트가 있는 경우에만 논의를 거쳐 진행하고자 한 것이다.
이러한 규칙을 나름대로 정하고 나니 더 이상 브랜치 및 코드 관리로 인한 불상사나 고민은 없어졌다.
추후에 다른 프로젝트를 진행할 때에도 각 프로젝트에 맞는 브랜치 전략을 잘 설정하는 것이 중요함을 깨달았다...
