해당 글은 2021년 7월 15일에 작성된 글입니다.
개발자라면 Git을 이용해 프로젝트 repository를 생성하고 commit 후 push 하는 작업은 누구나 할 수 있는 영역일 것입니다. 저 또한 입사하기 전까지는 대부분 혼자 프로젝트를 담당해 왔기 때문에 코드를 관리해봤자 dev브랜치에 작업한 후 master에 병합하는 정도였습니다. 하지만 현재 입사한 개발팀은 총 8명(앞으로 더 늘어날 예정) 그중 저와 긴밀하게 코드를 공유를 해야 하는 팀원은 팀장님 포함 3명이니 위와 같은 간단한 코드 관리로는 정확하게 어떤 코드가 변경되었는지 실시간으로 파악하기 어렵다는 생각이 들었습니다. 그래서 Git-Flow, GitHub-Flow, GitLab-Flow를 조사하고 팀에 어울리는 Flow는 무엇일지 생각해 보는 시간을 가져봤습니다.
Git-Flow
Git-flow는 10년전 Vincent Driessen이라는 사람이 효율적인 브랜치 모델에 관한 글을 자신의 블로그에 작성하였고 이 글이 많은 사람들에게 공유되어 Git으로 개발할 때 표준과 같이 사용되는 방법론입니다. 말하자면 Git-Flow는 하나의 기능이 아니고 Git사용에 관한 서로 간의 약속을 나타냅니다. Vincent Driessen도 언급했듯이 Git-Flow가 완벽한 방법론이 아니니 각자의 개발환경에 맞춰 변형해서 사용하라 언급했습니다.
Git-Flow는 5가지의 브랜치를 사용합니다.
- master(main): 릴리즈를 할 때 사용하는 최종 단계의 메인 브랜치입니다. Master브랜치는 릴리즈 기록을 담고 있습니다. 태그를 통해 versioning을 하게 됩니다.
- develop: 다음 릴리즈 버전 개발을 진행하는 브랜치입니다. 어떤 기능의 구현이 필요해지면 Develop브랜치에서 다시 브랜치를 내어 개발을 진행하며, 개발이 완료된 기능은 다시 Develop브랜치로 병합됩니다.
- feature: Develop브랜치에서 기능 구현을 이유로 브랜치를 생성할때 사용하는 브랜치, 한 단위 기능을 개발하는 브랜치, 개발이 완료되면 develop브랜치에 Merge 하고 제거합니다.
master와 devlop이 중요 브랜치이고 나머지는 필요에 의해 운영되는 브랜치라고 생각하면 됩니다.
- release: master에 병합하기전에 검증하기 위한 브랜치
- hotfix: master에 배포했는데 긴급 수정이 필요한 경우 사용합니다.
Vincent Driessen의 블로그 참조
주관적인 생각
Git-Flow는 엄격한 브랜치 전략과 계획적인 릴리즈 스케줄링이 필요한 대규모 프로젝트에 적합하다고 생각합니다. 시작단계인 푸시 뉴스 프로젝트에 입혀보면 불필요한 절차와 다소 복잡해 보이는 모델 같습니다. 2017년에 작성된 글이지만 배달의 민족은 규모가 커짐에 따라 Flow정책을 GitHub-Flow에서 Git-Flow로 변경했습니다.
GitHub-Flow
Git-Flow의 복잡한 절차를 조금 더 간단하게 줄인것이 GitHub-Flow입니다.
GitHub-Flow 다이어그램
Github flow는 Master브랜치가 릴리즈에 있어서 절대적인 역할을 합니다. Master(Main) 브랜치는 항상 최신 버전을 유지합니다. 그리고 무조건적으로 안정적인 상태를 담보해야 됩니다. Develop브랜치가 존재하지 않고 Feature와 Bugfix브랜치는 Master브랜치에서 생성되며, 병합됩니다. 병합을 할 때는 무조건 pull request를 하여 코드에 대한 검토를 받도록 합니다
사용법
- Master브랜치는 언제든지 배포가 가능한 환경이어야합니다.
- Master브랜치는 항상 최신의 상태이며, 안정적인 상태로 배포되어야 하는 브랜치입니다. 그러므로 이 브랜치에 병합하기 위해서는 많은 Pull Request를 통한 코드 검증이 필요합니다. 또한 병합이 일어났을 때 자동적으로 배포되는 환경을 구축해 놔야 됩니다.
- 새로운 작업을 하기 위해 생성되는 브랜치는 master로부터 분리되어야 하며 브랜치의 이름은 기능단위로 작성해야 됩니다.
- Git-Flow와 다르게 GitHub-Flow는 feature나 develop브랜치가 없기 때문에 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치의 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해 줘야 됩니다. 이렇게 하면 Github 페이지에서 어떤 일들이 진행되고 있는지를 확인하기 쉬워집니다.
- 원격 브랜치에 수시로 Push 합니다.
- 파일을 추가, 편집 또는 삭제할 때마다 커밋을 만들고 브랜치에 추가합니다. 커밋을 추가하면 작업 중인 브랜치의 진행 상황을 추적할 수 있습니다. 커밋은 팀원들이 내가 한 일과 그 이유를 이해할 수 있어야 합니다. 또한 각 커밋은 별도의 변경 단위로 간주되므로 버그가 발견되거나 다른 방향으로 향하기로 결정한 경우 변경 사항을 롤백할 수 있습니다. 그러므로 커밋 작성의 공통적인 폼이 필요합니다.
- 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성합니다.
- 기능에 대한 리뷰와 검증이 끝났다면 master로 merge 합니다.
주관적인 생각
GitHub-Flow가 가장 프로젝트에 어울리는 코드관리 형태인 것 같습니다. 이유는 프로젝트 초기에는 지속적인 배포가 이루어질 것이고 많은 수정요청과 피드백을 반영하기 위해서는 복잡한 Git-Flow보다는 단순화된 GitHub-Flow가 적합하다고 생각됩니다. 또한 기능단위의 브랜치 생성으로 팀원들의 작업내역을 한눈에 확인할 수 있으며 보편화된 pull request를 통해 팀원들의 코드를 공유하여 자연스럽게 코드의 품질을 높일 것으로 예상됩니다. 하지만 브랜치 네이밍과 커밋 작성의 폼을 팀원들과 의논해서 공통된 양식을 만드는 것이 중요해 보입니다.
GitLab-Flow
GltLab-Flow 다이어그램
단순해진 Github-Flow에 보완하는 내용을 가미하여 제안된 방식이 Gitlab-Flow입니다. Gitlab에는 Production 브랜치가 있는데, 이는 Git-Flow의 Master브랜치역할과 같습니다. Gitlab-Flow의 Master브랜치는 Production 브랜치로 병합합니다. 이렇게 브랜치 전략을 가져갈 때의 이점은 Production브랜치에서 릴리즈 된 코드가 항상 프로젝트의 최신버전 상태를 유지해야 할 필요가 없다는 것입니다.
주관적인 생각
Git-Flow와 GitHub-Flow의 절충안이라는 느낌을 줍니다. 결론적으로 아직까지는 프로젝트 흐름과는 맞지 않습니다. Web페이지를 구현하는 것이라 즉각적인 버그 수정과 실시간 업데이트가 중요하다고 봅니다. IOS앱처럼 정확한 출시시간을 제어할 수 없거나 회사 내에 엄격하게 정해진 배포시간이 있을 때 GitLab-Flow를 적용하는 것이 좋아 보입니다.
마치며…
지금까지 3개의 코드관리 Flow를 알아봤습니다. 결과적으로 팀에 어울리는 Flow는 GitHub-Flow로 판단했으며 다음 글에는 GitHub-Flow 환경 구현방법과 브랜치 네이밍, 공통적인 커밋 폼 작성방법에 대해 알게 된 것을 정리해 보겠습니다. 읽어주셔서 감사합니다🙇🏻♂️
참고
- https://nvie.com/posts/a-successful-git-branching-model/(git flow 창시자)
- https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html(배민 기술 블로그 — Git-flow를 사용한 이유)
- https://guides.github.com/introduction/flow/ (github-flow 공식글)
- https://about.gitlab.com/blog/2014/09/29/gitlab-flow/ (gltlab-flow 공식 블로그)
'기억보단 기록을 > Git' 카테고리의 다른 글
| GitHub Conventional Commit Message (0) | 2023.05.17 |
|---|
