[Git] Git Flow/Merge(Squash/Rebase)(Fast-forward/ Recursive Merge)

목차

1. 왜 Git Flow를 알아야 하는지?
2. Git Flow란?
   1. git repository
   2. git flow 전략
   3.  merge 방식
      
      1. Merge
         1. Fast-forward
         2. Recursive
      2. Squash and merge
      3. Rebase and merge

---

1. 왜 Git Flow를 알아야 하는지?

Android든 Web이든... 어떤 프로젝트의 버전 관리를 하려면 git 사용은 필수다.

 

큰 프로젝트일수록 협업하는 인원도 많아질텐데

여러 인원이 하나의 repository에 commit, push, merge하는 과정에서

누가/어떤 내용을 개발(또는 수정)했는지 관리하기 복잡해질 수밖에 없다.

 

이런 복잡성을 없애고, 프로젝트 관리를 쉽게 만들어주기 위한 약속이 Git Flow다.

 

branch를 어떻게 활용해야 하는지,

commit message는 어떻게 작성해야 좋은지 등등

git에 관한 이런 기본 약속들을 지키면

커밋 내용만 보고 어떤 내용을 수정/개발했는지 바로 파악할 수 있고,

프로젝트가 현재 어떤 상황인지도 알기 쉬워진다.

 

2. ...Git Flow란?

2.1 Git Repository

https://techblog.woowahan.com/2553/

• Git Repository
  • Upstream Remote Repository: 개발자들이 공유하는 저장소. 최신 소스코드가 저장되어 있는 원격 저장소
  • Origin Remote Repository:  Upstream Repository를 Fork한 원격 개인 저장소
  • Local Repository: 내 컴퓨터에 저장되어 있는 개인 저장소

 

2.2 Git-flow 전략 

Git-flow에는 5가지 종류의 브랜치가 존재한다.

• 항상 유지되는 메인 브랜치들
  • master: 제품으로 출시될 수 있는 브랜치
  • develop: 다음 출시 버전을 개발하는 브랜치
• 일정 기간 공안만 유지되는 보조 브랜치들
  • feature: 기능을 개발하는 브랜치
  • release: 이번 출시 버전을 준비하는 브랜치
  • hotfix: 출시 버전에서 발생한 버그를 수정 하는 브랜치

위 그림의 흐름은 다음과 같다.

1. 처음에는 master와, master에서 시작된 develop 브랜치가 존재한다.

2. develop 브랜치: 상시로 버그를 수정한 커밋들이 추가된다.

3. feature 브랜치: 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 한다.

5. release 브랜치: develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면, QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다. (QA를 진행하면서 발생한 버그들은 release 브랜치에 수정된다) QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 한다.

8. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

 

+ merge 순서는 feature > develop > release > hotfix > master이다. (앞에서 뒤로)

 

3. merge 방식

이때 merge 방식에는 3가지가 있다.

1. Merge
2. Squash and merge
3. Rebase and merge

 

3.1 Merge

git merge <브랜치명>

일반적으로 많이 사용되는 병합 방식이며, 커밋 내역을 모두 남길 때에 사용된다.

merge는 두가지의 병합 방식이 있다.

1. Fast-forward

2. Recursive

3.1.1 Fast-forward

$ git merge develop
Updating c77ebbe..dff05fa
Fast-forward     // <<< 이부분!
 develop.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 develop.txt

master에서 분기된 develop이 master의 모든 내용을 포함하고 있을 때의 merge 방식이다.

develop에서 추가한 B, C, D 커밋이 master와 분기된 시점 이후로 그대로 merge된다.

3.2.2 Recursive Merge

$ git merge develop
Merge made by the 'recursive' strategy.			// <<< 이부분!
 develop.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 develop.txt

master에서 분기된 develop이 master의 모든 내용을 포함하고 있지 않을 때의 merge 방식이다.

(ex B: hotfix에서 오류를 수정한 커밋이 될 수 있음)

master의 B와 develop에서 추가한 B, C, D 커밋을 합친 새로운 커밋 메시지(F)를 만들어서 merge하게 된다.

 

3.2 Squash and merge

git merge --squash <브랜치명>

분기된 develop 브랜치에서 커밋이 이루어지고(B, C, D)

커밋된 내용을 master 브랜치로 가져와 새로운 커밋(E)을 만든 뒤

브랜치를 없애 브랜치 커밋 명세들을 지우는 merge 방식이다.

 

3.3 Rebase and Merge

git rebase <base 브랜치명>
git checkout <base 브랜치명>
git merge <분기된 브랜치명>

분기된 develop 브랜치에서 커밋이 이루어지고 커밋된 내용(B, C, D)을 master 브랜치에 rebase를 통해 추가 커밋 메시지 없이 merge되는 것을 말한다.

 

 

 

git flow 외에도 github flow, gitlab flow가 있다.

이는 이곳에 잘 정리되어있으니 여기 함 봐보느 거 추천!

---

침고

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

https://mangchhe.github.io/git/2021/09/04/GitMerge/

[Git] 세 가지의 Merge 방식