안녕하세요, 리케어랩 프론트개발팀에서 웹 개발을 담당하고 있는 안승찬입니다.
오늘은 저희 웹 개발 팀에서 사용하고 있는 Git 브랜치 전략에 대해 소개해드리려고 합니다. 현재의 관리 플로우가 반드시 정답이라고 생각하지는 않지만, 저희 팀의 Git-flow 도입 과정에서 많은 시행착오를 겪으며 얻은 경험이 독자분께도 도움이 되었으면 좋겠습니다.
Git-flow를 사용하게된 이유
제가 입사하기 전에는 팀원 두 분이 레포를 관리하고 계셨습니다. 당시에는 두 분이 작업을 하셨기에 별도의 명확한 정의 없이 자연스럽게 작업이 진행되었습니다. 그러나 제가 입사하여 팀원이 세 명으로 늘어나면서, 막연히 `master` 브랜치에서만 분기하여 작업을 진행하다 보니 충돌 및 작업 상황 공유 등 여러 문제에 직면했습니다. 특히, dev 서버 없이 master에 바로 병합하다 보니 실제 서비스 환경에서 오류가 발생하는 경우가 잦아졌습니다. 또한 결제 시스템 등 고정 IP가 필요한 경우가 생길 때마다 master에서 테스트를 진행해야 하는 상황을 보며
"아 이건 관리가 필요하다"
라는 생각을 하게 되었습니다.
Git-flow의 도입
*초기 도입
저희는 develop 브랜치를 만들어 develop에서 분기하여 작업을 진행한 후, QA를 거쳐 배포하면 메인 서버에서 오류가 줄어들지 않을까 하는 생각으로 Git-flow를 도입했습니다. release 브랜치를 사용하는 방식도 많이 보았지만
"저희 상황에서는 굳이??" 라는 생각을 했던 것 같습니다.
이게 맞아요...?
"네. 굳이 그래야 됐었습니다."
저희는 초기 스타트업이기 때문에 빠른 개발과 신규 기능, 수정·오류 해결이 계속 요구되는 상황이었습니다. 신규 기능을 dev에 올리더라도 메인에서 오류가 발생하면 기존 커밋을 reset하는 경우가 빈번해졌고, 커밋이 꼬이면서 실수가 발생하기 시작했습니다. 결국 저희는 다시 3시간의 열띤 토론 끝에 release 브랜치를 통한 버전 관리의 필요성을 절감하게 되었습니다.
버전 관리 시작...
"네. 글로 정리해서 짧아 보이는데 장장 2개월동안 저희 모두 고생했습니다."
이 전략을 모두 처음에 알고 있었지만, 저희 다 주니어 였기에 명확히 옳다 틀리다를 말해줄 사람이 없었습니다.
release 브랜치를 도입하면서 저희가 고민했던 문제들을 해결할 수 있었습니다. 이제 메인 브랜치에서 오류가 발생하더라도 release 브랜치를 통해 hotfix로 수정할 수 있었고, 개발 중인 develop 브랜치에는 영향을 주지 않게 되었습니다. QA 중에는 release에서 수정한 후 최종 배포 단계에서 master와 develop에 모두 병합하는 방식으로 문제를 해결할 수 있었습니다.
나름의 규율
저희도 개발을 진행하면서 나름대로의 규율를 만들고 지킬려고 노력했던것 같습니다.
-
master : 제품으로 출시될 수 있는 브랜치
-
develop : 다음 출시 버전을 개발하는 브랜치
-
feature : 기능을 개발하는 브랜치
-
release : 이번 출시 버전을 준비하는 브랜치
-
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
PR의 경우는 한명 이상의 동료 승인이 있을시만 진행
작업을 시작하기 전에 JIRA 티켓을 생성합니다(hotfix의 경우도 무조건!)
하나의 티켓은 되도록 하나의 커밋
자신의 Pull Request는 스스로 merge 합니다.
마무리
Github-flow일 때보다 늘어난 브랜치들을 관리 해야 하는 부담은 늘었지만 전보다 일관되게 여러 상황들을 대처할 수 있는 것 같습니다.
물론 모든 상황이 flow대로 흘러가지는 않는 것 같습니다.(아직... 저희가 부족해서 그런 것 같지만...)
하지만 여러 시행착오를 겪으면서 발전해 왔다고 생각해서, 또 다른 문제를 직면한다고 해도 저희 끼리 잘 해쳐 나갈 것 같습니다.
항상 정답은 없다고 생각하기에, 읽어주신 분 모두 자신의 상황에 맞는 브랜치 전략을 선택하실 수 있기를 바랍니다.
감사합니다.
