[ Weekly Paper2 ] - Git merge과 git flow branch 전략

YUYONI·2023년 12월 2일

스프린트프론트엔드3기 취업까지달린다 코드잇스프린트

코드잇 스프린트 3기

목록 보기

11/31

Git branch merge 전략

: 현재 branch에서 다른 branch를 합치는 것

: 작업 내용을 합쳐야 하거나 협업 시 서로 다른 branch에서 작업을 한 경우 merge를 해주면 됨

: merge하는 방법으로는 일반적인 Merge commit을 남기는 방법, Squash and merge, Rebase and merge 세 가지 방법이 존재함

1. 기본 merge

일반적으로 많이 사용하는 merge 방법으로, 커밋 이력을 모두 남길 때 사용
git merge branch이름 으로 병합
현 branch와 병합할 branch가 Fast-forward 관계이면 Fast-forward 병합을 진행, 그렇지 않은 경우 Merge 커밋을 생성하여 3 way-merge를 진행

fast-forward 방식

두 branch가 선형적으로 연결되어 있고, Base branch가 이후 변경 내용이 없는 최신 branch일 경우
현재 branch의 헤드를 병합하려고 하는 branch의 최신 커밋으로 이동
장점: 간단하고 깔끔한 히스토리 유지
단점 : branch의 독립적인 히스토리는 없어짐

3-way-merge

두 branch가 독립적으로 발전했을 때
두 branch의 공통 조상(base)을 찾아 이를 기반으로 두 branch의 변경 사항을 통합하는 새로운 'merge commit'을 생성
장점: branch의 독립적인 히스토리 유지
단점 : 복잡한 히스토리

만약 파일 A,B,C,D 가 있고, my_branch에서 A', C'로 변경하고 other에서 C'', D'로 내용을 변경했다면 merge commit에서는 아래와 같이 통합됨

2. Squash and merge

merge할 branch의 커밋을 전부 하나의 커밋으로 합친 뒤 타겟 branch에 커밋하는 방식으로 merge
commit history를 합쳐서 깔끔하게 만들기 위해 사용
장점: 깔끔한 히스토리
단점 : 개별 커밋 히스토리 손실

3. Rebase and merge

branch의 공통 조상이 되는 base를 다른 branch의 커밋 지점으로 바꾸는 것
즉, branch의 커밋 지점을 재설정(Rebase)하는 것
main branch의 마지막 커밋인 B 이후에 other의 변경사항인 A'과 B'가 일어난 것처럼 보이게 하고 싶은 것
장점: 선형적인 히스토리
단점: Base가 변경돼 커밋 해시 또한 변경 될 수 있음

커맨드 정리

$ git merge {병합할 branch 명} : 기본으로 --ff(fast forward)옵션. 현 branch와 병합할 branch가 Fast-forward 관계이면 Fast-forward, 아니 merge commit을 생성해 3 way-merge

$ git merge --no-ff {병합할 branch 명} : Fast-forward관계 여부와 상관없이 Merge 커밋을 생성하여 병합.

$ git merge --ff-only {병합할 branch 명} : 현재 branch와 병합 대상의 관계가 Fast-forward인 경우에만 병합을 진행. Merge 커밋 생성X

$ git merge --squash {병합할 branch 명} : merge할 branch의 커밋을 전부 하나의 커밋으로 합친 뒤 타겟 branch에 커밋하는 방식으로 merge를 진행

$ git rebase {병합할 branch 명} : 분기했던 branch의 기준을 최신 Base로 설정하고, merge하는 방법. rebase 후 merge해주면 결과적으로는 git merge -ff 와 같은 형태가 됨

Git Flow branch 전략

: Git Flow는 Vincent Driessen이 설계한 전략으로, 효율적인 소프트웨어 개발과 유지보수를 위해 설계됨
: 다양한 유형의 branch를 사용하여 개발 프로세스를 명확하게 정의함

장점: 프로젝트 규모가 크거나 실제로 배포할 경우 버그 수정 등에 용이함
단점: branch가 많아서 관리하기 복잡함. 프로젝트 규모가 작으면 비효율적

크게 Main branch, Develop branch, Supporting branch로 구분하여 branch를 관리
Supporting branch는 또 다시 Feature branch, Release branch, Hotfix branch로 나뉨

Main branch

출시 가능한 프로덕션 코드를 모아두는 branch로 프로젝트 시작 시 생성
개발 프로세스 전반에 걸쳐 유지, 배포된 각 버전을 Tag를 이용해 표시해둠

Develop branch

다음 버전 개발을 위한 코드를 모아두는 branch
개발 완료 시 Main branch로 merge

Feature branch

하나의 기능 개발을 위한 branch
Develop branch에서 생성하며, 기능 개발 완료 시 다시 Develop branch로 merge
( 이 때, Fast-Forward로 merge하지 않고, Merge Commit을 생성하며 merge를 해줘야 특정 기능 단위로 히스토리 묶임 )
네이밍은 feature/branch-name 과 같은 형태로 생성

Release branch

소프트웨어 배포를 준비하기 위한 branch
Develop branch에서 생성하며, 버전 이름 등 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용
배포 준비 완료 시 Main과 Develop branch에 둘다 merge
이때, Main branch에는 Tag를 이용하여 버전 표시
Release branch를 따로 만들어 놓으면, 배포 업무와 관련없는 팀원들은 병렬적으로 Feature branch에서 이어서 기능을 개발할 수 있음
네이밍은 release/v1.1 과 같은 형태로 생성