[Git] Git branch merge / Git Flow 브랜치 전략

Q. 질문 1

Git에서 branch merge 방법들과 각 방법의 특징을 설명해 주세요.

 (코드잇 스프린트 위클리 페이퍼 #3)

A. 답변 1

branch merge 란?

Git 에서 branch merge 란?

 

branch merge
현재 branch 에서 다른 branch 를 합친다.(병합)

 

branch merge 를 사용하는 상황은 다음과 같다.

• A branch 에서 작업을 한 내용을 main branch 에 반영하기 위해, main branch 에서 A branch 의 내용을 합침
• A branch 에서 작업하고 있는데 main branch 에 최신 변경 사항이 있어, A branch 에서 main branch 의 내용을 합침

 

branch merge 방법

branch 를 merge 하는 방법에는 크게 merge, squash, rebase 3가지가 있다.

 

1. merge

기본적으로 사용되는 merge 방법이다.

merge 는 두 브랜치를 병합할 때 전에 생성된 커밋과 히스토리를 유지하면서 병합을 한다는 특징이 있다.

git merge <병합할 브랜치>

 

2. squash

squash 는 병합할 브랜치의 커밋 메시지들을 합쳐 하나의 커밋 메시지를 만들어 merge 를 한다.

그래서 여러 개의 커밋 메시지를 한 개의 커밋 메시지로 합치게 되어 커밋 히스토리를 간결하게 만들 수 있다.

반면 추후에 어떤 내용들이 변경되었는 지 알기 어렵다는 단점이 있다.

git merge --squash <병합할 브랜치>

 

3. rebase

rebase 는 현재 브랜치에 있는 커밋들이 재베이스할 브랜치의 새로운 커밋 아이디를 가진 커밋으로 새로 추가된다.

그래서 히스토리가 깔끔하게 유지되지만, 코드가 충돌될 가능성이 높다는 단점이 있다.

git rebase <재베이스할 브랜치>

 

Q. 질문 2

Git Flow 브랜치 전략에 대해 설명해 주세요.

 (코드잇 스프린트 위클리 페이퍼 #3)

 

A. 답변 2

Git Flow 브랜치 전략이란?

헙업을 하기 위해 branch 에서 작업을 하게 되는데, 이러한 branch 를 규칙을 없이 마음대로 생성하면 어떤 기능을 하는 브랜치인지 의문이 생기는 등 혼란이 온다.

 

그래서 이를 해결하기 위해 Git Flow 브랜치 전략을 세워야 한다.

 

Git Flow 브랜치 전략
프로젝트를 효과적으로 관리하기 위한 Git 브랜치를 효과적으로 관리하기 위한 워크플로우

 

Git Flow 브랜치 전략

Git Flow 는 A successful Git branching model 이 대중적으로 사용되게 된 브랜치 전략이다.

 

Git Flow는 크게 Main 브랜치, Develop 브랜치, Supporting 브랜치로 구분하여 브랜치를 관리한다.

이때, Supporting 브랜치는 또다시Feature 브랜치, Release 브랜치, Hotfix 브랜치로 나뉜다.

 

Main 브랜치

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

 

Develop 브랜치

다음 버전 개발을 위한 코드를 모아두는 브랜치이다. 개발이 완료되면, Main 브랜치로 merge 된다.

 

Feature 브랜치

하나의 기능을 개발하기 위한 브랜치이다.

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

 

Release 브랜치

소프트웨어 배포를 준비하기 위한 브랜치이다.

Develop 브랜치에서 생성하며, 배포 준비가 완료되었다면 Main과 Develop 브랜치에 둘 다 merge 한다.

 

Hotfix 브랜치

이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결한다.

Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 merge 한다.

 

+) 현재 사용 중인 전략

지금 팀 프로젝트를 진행하고 있는데 나는 아래 사진에 있는 GitHub Flow 전략을 사용하고 있다.

노션에서 캡쳐한 브랜치 전략

 

저번 프로젝트에서는 그냥 본인 이름 대로 브랜치를 만들어서 작업을 했지만

이번 프로젝트는 브랜치를 feat / refactor / chore / hoxfix 로 분류하고, 이슈 번호와 기능을 적어 이 브랜치에서는 어떤 기능을 하는지 명확하게 알 수 있게 된다.

 

기능 단위로 개발을 하다 보니 작은 변경 사항을 빠르게 반영할 수 있고 merge 할 때 main 브랜치와 충돌이 적게 발생한다.

또한 각자가 작업한 변경 사항을 주기적으로 공유하고 피드백을 주고받을 수 있어 협업에 유용하다.

 

+) 참고

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