Git Flow와 Github Flow

Git Flow

Git Flow, Github Flow 모두 협업 시 브랜치들의 효율적 관리를 위한 브랜치 관리 전략 또는 방법론들이다. 먼저 Git Flow 전략에 알아보자~!

Git Flow 5가지 브랜치

Git Flow에는 5가지 종류의 브랜치가 있다.

master, develop ➡️ 항상 유지되는 메인 브랜치들

feature, release, hotfix ➡️ 필요할 때마다 생성되고, 역할을 다하면 삭제되는 보조 브랜치들

📌 master 브랜치

출시 가능한 프로덕션 코드를 모아두는 브랜치

master 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해 둔다.

📌  develop 브랜치

다음 버전 개발을 위한 코드를 모아두는 브랜치

개발이 완료되면, master 브랜치로 머지된다.

master에서부터 시작된 브랜치. 상시로 버그를 수정한 커밋들이 추가됨.

어느 시점에 반영이 됐는지 보기 위해서 merge + rebase를 이용해서 Git Flow를 예쁘게 본다.

📌  feature 브랜치

하나의 기능을 개발하는 브랜치

Develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 Develop 브랜치로 머지된다.

git flow를 깔끔하게 보기 위해 origin develop의 갈라나온 시점을 잘 관리해 주어야 한다.

git pull --rebase origin devlop 을 이용해서 제일 마지막에 반영된 develop에서 branch가 갈라 나온 것처럼 보이게 한다. 즉 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게 해야 히스토리가 특정 기능 단위로 묶이게 된다.

네이밍은 feature/branch-name과 같은 형태로 생성한다.

📌 release 브랜치

이번 출시 버전을 준비하는 브랜치

Develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그(QA)를 수정하기 위해 사용된다. 배포 준비가 완료되었다면 master와 Develop 브랜치에 둘 다 머지한다. 이때, master 브랜치에는 태그를 이용하여 버전을 표시한다.

Release 브랜치를 따로 운용함으로써, 배포 업무와 관련 없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있게 된다.

네이밍은 release/v1.1과 같은 형태로 생성한다.

📌 hotfix 브랜치

이미 배포된 버전에서 발생한 버그를 수정하는 브랜치

master 브랜치에서 생성하며, 문제 해결이 완료되면 master와 Develop 브랜치에 둘 다 머지한다.

Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 운용함으로써, 핫픽스 업무와 관련 없는 팀은 병렬적으로 기능 개발을 할 수 있다.

네이밍은 hotfix/v1.0.1과 같은 형태로 생성한다.

Git-flow 전략을 설명하는 그림

출처 : 우아한 기술 블로그

 

Github Flow

Github Flow는 깃허브(GitHub)를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것이다. Github Flow는 Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.

master 브랜치의 역할만 확실히 지켜진다면 다른 브랜치에 대해 관여를 하지 않는다. 즉, master 브랜치를 제외하고 feature, hotfix, bugfix 등등의 브랜치를 구분하지 않는다. 또한 pull request 기능을 사용하도록 권장을 하며 수시로 배포가 발생하므로 CI/CD가 자동화되어 있는 환경에서 사용하기 좋다. 그렇다면 Github Flow에 대해 자세히 알아보자.

 

브랜치

📌 master 브랜치

master는 항상 최신 상태를 유지해야 하며 production(live) 환경에 배포할 수 있어야 한다. 또한 해당 브랜치에 merge를 하기 전에 충분한 테스트를 거쳐야 한다.

📌 feature 브랜치

브랜치는 항상 master 브랜치에서 생성해야 하며 git flow에 존재하는 feature 브랜치나 develop 브랜치가 존재하지 않기 때문에 새로운 기능 추가, 버그픽스와 같은 브랜치 이름은 자세하게 어떤 일을 하는지에 대해 작성해야 한다.

예를 들면, user-content-cache-key, submodules-init-task, redis2-transition 등이 있다.

 

참고 : jira와 같은 툴을 사용하고 있다면 JIRAKEY-브랜치명으로 지어주면 좀 더 수월할 것 같음.

 

사용 시 유의할 점

origin 브랜치에 수시로 push

내 작업물을 수시로 서버에 push 하여 다른 사람들이 확인할 수 있도록 한다. 이는 github 뿐만 아니라 git 사용에 공통적인 부분이다.

도움, 피드백, master에 merge를 준비할 때 Pull Request를 생성

Pull Request는 코드 리뷰를 도와주는 시스템으로 가장 핵심이다. 내가 짠 코드를 공유하고 팀원들에게 리뷰를 받고 완료되었다면 master 브랜치로 merge를 진행한다.

master 브랜치에 merge가 되고 push가 되었을 때, 즉시 배포

여기서 CI/CD를 자동화하여 master 브랜치에 배포되었을 때, 테스트와 빌드를 자동으로 거친 후 이상이 없다면 production에 자동으로 반영이 되어야 한다.

해당 전략은 master 브랜치에 merge가 수시로 발생하므로 수동으로 하기엔 적절하지 않다.

merge 한 이후 요청한 브랜치는 삭제

merge한 이후 요청한 브랜치를 삭제하는 것은 작업이 완료되었음을 나타내며 팀원이나 내가 실수로 오래된 브랜치를 사용하는 것을 방지할 수 있다.

브랜치 삭제는 간단하게 진행할 수 있으며, 삭제한 브랜치를 복원하는 것 또한 간단하게 처리할 수 있다.

 

❓그렇다면 어떤 프로덕트에 적합할까

 

 Git Flow  → 소규모 개발팀, 웹 애플리케이션(단일 버전 존재)

 Github Flow → 대규모 개발팀, 앱 애플리케이션(버전 여러 개)

 

- -Vincent Driessen 글 中-

Git-Flow는 등장하고 10년 넘게 표준처럼 자리 잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기 있는 유형의 소프트웨어가 웹 애플리케이션으로 이동하고 있다. 웹 애플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.

웹 어플리케이션은 내가(Vincent Driessen) 10년 전 블로그 글을 쓸 때에는 염두에 둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.

그러나 명시적으로 버전을 관리해야 하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.

 

 

즉, Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 애플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합하다. 유명한 글인 우아한 형제들 기술 블로그에 우린 Git-flow를 사용하고 있어요 글을 작성한 팀도 안드로이드 앱 개발팀이다.

 

웹 애플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하게 된다.

여러 버전을 병렬적으로 지원할 필요가 없는 것이다. 또한 웹 애플리케이션은 하루에 몇번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.

 

개발팀이 소규모 애자일 팀이고, 제품이 단일 릴리즈 버전밖에 존재하지 않는다면 Github Flow가 적절하다. 대부분의 웹 애플리케이션은 여러 버전을 관리하지 않고, 가장 최신 버전 하나만을 사용자가 사용하게 된다.

Github Flow는 하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포할 수 있는 구조로, 진정한 의미의 CI/CD를 실천하기 적합한 브랜치 전략이 아닐까 한다.

 

출처 : https://hudi.blog/git-branch-strategy/