Workflow의 중요성
지난 시간에 공부했듯이 Git으로 프로젝트를 관리할 때는 브랜치로 관리한다. 브랜치를 활용하여 손쉽게 백업하고 분할 작업이 가능하도록 하여, 보다 안전하고 효율적으로 작업할 수 있다.
그렇다고 무턱대고 브랜치를 생성하다보면 각 브랜치의 역할을 구분하기가 불가능해지면서 작업이 난잡해지기 때문에 결국에는 대참사로 이어질 가능성이 있다.
우리는 이것을 방지하기 위해 생성할 브랜치의 역할을 미리 명시할 필요가 있다.
Git Workflow
Git Workflow는 브랜치를 사용하는 규칙들을 명시해둔 개념이며, 대표적으로 Git Flow, Github Flow, Gitlab Flow 가 있다.
Git Flow
가장 대표적인 브랜치 전략로 대규모 프로젝트에 적합하다.
5가지 종류의 브랜치로 관리된다.
- master(main): 제품으로 출시될 수 있는 브랜치
- develop: 다음 출시 버전을 개발하는 브랜치
- feature: 기능을 개발하는 브랜치
- release: 이번 출시 버전을 준비하는 브랜치
- hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치
master는 배포된 상태의 버전이 포함되어 있기 때문에 프로젝트의 원본이 저장된 브랜치라고 할 수 있다.
develop은 원본 파일을 수정하는 것은 위험하기 때문에 만들어진 복사본으로 실질적인 메인 브랜치 역할을 한다.
feature는 말그대로 기능을 개발하는 브랜치이다. 예를 들어, 로그인 기능을 추가하고 싶다고 한다면 ‘feature/login’ 이라고 생성하여 기능을 개발한다.
release는 develop에서 개발된 기능들을 출시하기 전에 테스트를 위해 사용되는 브랜치이다. QA 등을 release 브랜치에서 진행하고, 정상적으로 완료되면 master 브랜치에 merge된다.
hotfix는 치명적인 버그가 발생한 경우 빠르게 대응하기 위해 master 브랜치에서 생성하여 사용한다.
Git Flow는 Vincent Driessen이 2010년 블로그에 올린 A successful Git branching 이라는 글이 인기를 끌며 현재까지 가장 대중적으로 사용하고 있는 전략이다. 안정성과 신뢰성을 바탕으로 설계된 프로세스의 명확성 때문에 많은 프로젝트에서 사용 되었다. 하지만, 장점이 명확한 만큼 한계점도 명확하다.
Git Flow의 한계
Vincent Driessen이 해당 글을 올린지 10년이 지난 2020년에 포스팅 위에 반성의 글(Note of Reflection)을 적는다. 누군가가 블로그에 잘 요약해두어서 가져와 봤다.
Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.
웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.
그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.
간단하게 말해서 CI/CD 파이프라인에는 적합하지 않다는 의미이다. 명시적으로 버전을 관리해야 하는 오픈소스 라이브러리/프레임워크, 스마트폰 어플리케이션 등의 프로젝트에는 적합하지만, 웹 같이 단일 버전이 지속적으로 제공되어야 하는 프로젝트의 경우에는 병렬적으로 버전을 지원할 필요가 없기 때문에 비 효율적이라는 것이다. 그래서 그 경우에는 보다 단순한 workflow를 사용할 필요가 있다.
Github flow
Vincent Driessen이 언급한 Github Flow는 이름 그대로 Github 환경에서 사용하기 적합한 브랜치 전략이다.
2가지 종류의 브랜치로 운영되기 때문에 상당히 단순하다
- Master: 메인 브랜치로 모든 커밋이 빌드되어 있음
- Topic: 새로운 기능 개발과 버그 수정을 위한 브랜치
Git Flow 기준으로 develop, release는 없애고, feature, hotfix를 topic이라는 하나의 브랜치로 묶었다.
Master 브랜치
가장 큰 특징이자 Github Flow가 강제하는 유일한 사항은 Master 브랜치는 항상 Stable해야 한다는 것이다. Master의 모든 커밋은 언제 배포하든 문제 없어야 하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. 따라서, Master 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다.
Topic 브랜치
Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍한다. 예를들어, user-content-cache-key, submodules-init-task 등과 같이 말이다.
또 다른 특징은 Topic 브랜치의 모든 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다는 것이다. 이것은 곧 구성원끼리의 끊임없는 커뮤니케이션을 가능하게 해준다. 또한, 이것은 Github의 PR과 이어진다.
Pull Request
Github에는 PR(Pull Request)라는 기능이 존재한다. 브랜치끼리 비교하여 변경내역을 보여주는 기능이다. 개발자들은 개설된 PR에서 코드리뷰를 주고 받고, Merge여부를 결정한다. PR을 통해 자연스로운 코드 리뷰가 가능해진다.
GitLab Flow
단순하여 출동에 대처하기 힘든 Github Flow의 단점을 보완하기 위해 나온 전략이다.
4가지 종류의 브랜치로 운영된다.
- master: Git Flow의 develop와 동일한 역할로 개발 단계의 코드가 포함된 브랜치이다.
- feature: 특정한 기능을 구현하는 브랜치로, 구현이 완료되면, master 브랜치로 PR을 날린다.
- production: Git Flow의 master 브랜치와 동일한 역할로 배포될 코드가 포함된 브랜치이다.
- pre-production: 배포 전에 테스트를 위한 브랜치로, 정상적으로 완료되면 production과 master 브랜치로 PR을 날린다.
가장 큰 장점은 pre-production 브랜치로 테스트함으로써 안정성을 확보함과 동시에 내장된 CI/CD 파이프라인을 제공하여 배포를 자동화할 수 있다는 점이다.
안정성이 확보된 프로젝트에서는 Github Flow가 더 효율적이지만, 더 복잡하거나 큰 규모의 프로젝트에서 Github Flow보다 더 효율적이다.
Reference
나동호, 2017.08.30, 우린 Git-flow를 사용하고 있어요, https://techblog.woowahan.com/2553/
Vincent Driessen, 2020.03.05, A successful Git branching model, https://nvie.com/posts/a-successful-git-branching-model/
Hudi, 2022.08.03, Git 브랜치 전략 (feat. Git Flow, Github Flow), https://hudi.blog/git-branch-strategy/
Github, https://githubflow.github.io/
