Git merge의 방법 & Git Flow Branch전략

**이미 지난 주차의 위클리 페이퍼이지만 블로그 이사로 인해서 새롭게 올리게 되었습니다.**

내용은 유사하지만, 조금 더 보완해서 게시했습니다!

 

- Git에서 branch merge 방법들과 각 방법의 특징을 설명해 주세요.
- Git Flow 브랜치 전략에 대해 설명해 주세요.

 

Branch Merge란?

: merge, 병합하다 합병하다라는 뜻으로, git에서 branch를 나누어 작업을 한 후 나누었던 브랜치들을 다시 합치는 것을 의미합니다.

 

1. Merge commit

: 합치는 것과 합쳐지는 것의 데이터를 모두 남기면서 새로운 커밋을 형성하는 방법

 

# 장점

• 히스토리를 보존할 수 있음 -> 프로젝트 진행상황 파악이 용이하다.
• 커밋 아이디가 바뀌지 않아서 squash나 rebase를 사용하기 쉽다.

# 단점

• 커밋이 많이 생성되기 때문에 복잡도가 높아진다.

---

2. Squash and Merge

: 모든 변경사항이 하나의 커밋으로 압축되어 새롭게 생성 됨

 

# 장점

• 커밋 히스토리를 간결하게 유지할 수 있다. -> 하나의 커밋이 PR을 대변하는 작업 단위를 가진다.

# 단점

• 작업의 상세한 이력을 잃는다.
• 각 커밋에 대한 개별적인 맥락이나 작업자의 정보 등이 포함되지 않아 추후 문제 발생시 해결이 어렵다.
• 기존의 커밋 아이디들이 하나로 합쳐지며 사라지기 때문에, 협업 중이었다면 복잡한 문제를 야기할 수 있다.

* Squash 방식을 사용해도 git 이 아닌 github에는 해당 커밋 기록들이 남아있어 Pull Request를 검색해 확인할 수 있다. *

---

3. Rebase and Merge

: 현재 브랜치를 target 브랜치에서 재위치 시킨 후, 병합하는 방식

 

# 장점

깨끗하고 선형적인 커밋 히스토리를 만들어준다. -> 히스토리 파악 및 코드 변화의 이해가 쉬움

 

# 단점

• 커밋 아이디가 바뀌어 혼란을 초래할 수 있다. -> 특히 브랜치가 크게 분기된 경우에는 더 어려울 수 있다.
• PR별 다른 기능으로 나뉘어져 있던 이력이 하나의 선형적인 히스토리로 합쳐진다. -> 특정 기능이 어디부터 어디까지의 커밋인지 보기 어려워진다는 의미

* 여러 개발자의 협업이 이루어진 상황이라면, rebase 방식은 복잡한 충돌을 야기한다 *

---

Git Flow 전략이란?

Git Flow

Git Flow 전략은 브랜치를 크게 Main, Develop, Supporting으로 구분하여 관리하는 Git 관리 기법이다.

이때 각각의 브랜치마다의 역할을 정하여 여러 개발자들이 병렬적으로 업무를 할 수 있게 해준다.

Main 브랜치

• 출시 가능한 프로덕션 코드를 모아두는 브랜치로, 개발 프로세스 전반에 걸쳐 상시 유지된다.
• 배포된 여러 버전이 있을 경우, 각 버전을 Tag를 이용해 표시해둔다.

Develop 브랜치

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

 

# Feature 브랜치

하나의 기능을 개발하기 위한 브랜치로, Develop브랜치에서 분기된다.

기능 개발이 완료 되면 다시 Develop 브랜치로 머지된다.

작업을 할 때는 " feature/function-name " 또는 " feat/function-name "으로 네이밍하여 작업한다.

 

이 외에도 다양한 브랜치들이 있지만, 주로 사용하는 브랜치는 위에 나열한 브랜치이다.

 

 

출처

- Git Flow 전략 
- 코드잇 강의 Git