📌 Git-flow
Git-flow는 2010년 온라인에서 nvie라는 닉네임을 사용하는 개발자에 의해 알려진 것으로, feature - develop - release - hotfix - master 로 브랜치를 구성한다.
Git-flow는 소프트웨어 버전 관리가 필요한 앱이나 솔루션 혹은 public API에 적합한 워크플로우이다.
따라서 웹 애플리케이션에서 Git-flow는 고려할 전략이 아니다.
📌 GitHub-flow
GitHub-flow는 2011년 GitHub CIO인 Scott Chacon이 처음 꺼낸 것으로, Git-flow의 가장 큰 문제점은 개발자가 요구하는 상황보다 훨씬 더 복잡한 프로세스라고 지적했다.
워크플로우를 단순화할수록 오버헤드가 발생하지 않아 브랜치 전략을 이해하지 못하여 생기는 문제가 사라진다고 말했다.
GitHub-flow의 유지 브랜치는 master 하나를 두는 방식이다.
master를 제외한 브랜치는 개발자 재량에 맡긴다.
master는 언제든지 배포 가능하다.- 새로운 프로젝트는
master를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.- 브래치는 로컬에 commit 하고, 정기적으로 원격 브랜치에 push 한다.
- 피드백이 필요하거나 코드 병합 준비가 되었다면 pull request를 만든다.
- 다른 사람이 변경된 코드를 검토한 뒤 승인하면
master에 병합한다.- 병합된
master는 즉시 배포할 수 있으며, 배포해야만 한다.
GitHub-flow는 상시 배포 모델로, 상시 배포하는 팀은 Git-flow보다 GitHub-flow가 적합하다.
📌 GitLab-flow
GitLab은 GitHub-flow가 지속 배포 모범 사례라는 점에 동의하나, 배포, 환경, 릴리즈 및 소스 통합 등 다양한 이슈에 대한 부족함을 지적했다.
따라서 GitLab은 GitHub-flow를 기반으로 상황에 따라 워크플로우를 활용하는 방법에 대해 추가적인 가이드를 제공한다.
- 배포 기간이 정해진 경우 발생하는 통합 이슈 해결책
- 서버 환경에 따른 브랜치 구성 방법
- 릴리즈 버전이
master와 분리되어 운영되어야 하는 상황 타개법- rebase를 활용한 commit 압축하기
- merge commit 줄이는 방법
- commit 메세지 작성 방법
- 기능 분기에 대한 정책
feature: 모든 기능 구현은feature브랜치에서 시작한다.feature브랜치는master브랜치에서 분기되고 머지된다.master: GitLab flow의master브랜치 역할은 git flow의develop브랜치와 동일하다.master브랜치는feature브랜치에서 병합된 기능에 대해 test를 진행한다. 전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면production브랜치로 머지한다. 만약 staging 단계를 원한다면pre-production브랜치로 머지를 진행한다.production: GitLab flow의production역할은 git flow의 master 브랜치와 동일하다. 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치이다.pre-production:master->production브랜치 사이에pre-production브랜치를 두어 변경사항을 바로production에 배포하지 않고, test server에 배포하여 통합 테스트를 진행하거나 시간을 두고 반영하는 브랜치이다.
GitLab이 내세운건 이슈 기반 트래킹이다.
코드를 변경하는 목적은 분명하므로 이슈로 생성하여 관리하자는 이념 아래로 코드 변경 사유를 투명하게 공개하자는 원칙이다.
GitLab은 동일한 rpository를 사용하는 개발자들끼리 작업 내역을 알아야 되며, 이슈를 기반으로 관리하면 브랜치 생명주기가 보다 명확하게 파악되어 유지보수가 용이하다고 말한다.
< 참고 : https://blog.hwahae.co.kr/all/tech/tech-tech/9507
https://brownbears.tistory.com/605
https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5 >
