[기타] Github Flow

Git'hub' Flow?
Git Flow는 다들 많이 들어봤을 것이다.다양한 브랜치를 운영하며 핵심이 되는 master 브랜치,develop 브랜치,feature 브랜치등을 운영하는 방법이다.그런데 Github Flow라고 들어봤는가? 기존의 고전적인 Git Flow 방식에서 벗어나 Github의 PR(Pull Request) 기능을 적극적으로 활용하는 방식의 관리 방식으로 후술하겠지만 간단하고 쉽게 익혀 사용할 수 있다.
Github Flow 전략

우선적으로,자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.기본적으로 master 브랜치에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 PR 기능을 사용하도록 권장한다.
흐름

- master 브랜치가 항상 배포 가능한 상태로 유지된다 – 안정된 버전만 여기에 존재합니다.
- 새로운 작업을 위한 feature 브랜치를 만든다 – master 브랜치에서 분기하여 ‘feature/…’ 또는 ‘fix/…’ 같이 목적에 맞는 브랜치 이름을 붙입니다.
- feature 브랜치에서 코드 작업을 진행한다 – 독립된 작업 공간처럼 기능 개발이나 버그 수정을 수행합니다.
- 작업 완료 후 main 브랜치로 Pull Request를 생성한다 – 변경 내용을 동료에게 리뷰 받고 테스트할 수 있도록 PR을 만듭니다.
- 동료들이 코드를 검토하고 승인을 한다 – 리뷰를 통해 문제를 발견하거나 코드 품질을 확인하고, 필요 시 수정을 요청합니다.
- 검토된 PR을 master 브랜치에 병합한다 (Merge) – 승인이 끝나면 병합하여 master 브랜치에 반영합니다.
- 병합 후 feature 브랜치는 삭제하고 로컬 main을 업데이트한다
Git Flow와 비교
Github Flow는 코드 리뷰와 PR을 기반으로 한 전략이고 Git Flow는 복잡하지만 체계적인 전략을 구축하여 버전의 무결성을 보장한다.안정성은 체계적인 Git Flow가 우세이지만 특유의 복잡성으로 인하여 병합 관리가 어렵고 배포 속도가 느리다는 문제점이 있을 수 있다.Github Flow는 대개 master,develop만 지속적으로 운영하고 이러한 방식은 직관적이고 배포와 핫픽스 속도가 비교적 빠르다.
단점..?
테스트,리뷰,버전관리 등에 충분한 자원을 투자할 수 있는 팀이라면 더 체계적이고 단단한 Git Flow를 사용하고 상황에 따라 유연하게 운영하는것이 더 좋을 것이다.이렇게 단언할 수 있는 이유는 단연하지만 여러개의 브랜치를 거치며 자연스럽게 예외를 탐지하고 이를 배포전 단계에서 확인 및 수정이 가능한데 Github Flow는 자동화가 잘 되어있지 않다면 문제가 생길 위협이 더 커질 수 밖에 없다.
결론
빠른 피드백과 반복 배포가 중요한 프로젝트에는 GitHub Flow가, 안정적 버전 관리와 단계별 릴리즈가 중요한 프로젝트에는 Git Flow가 더 적합하다. 실제로는 두 전략을 혼합해서 사용하는 팀도 많다.