[3주차] Git branch merge 방법 / Git Flow 브랜치 전략

3주차 위클리 페이퍼 과제

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

A. 일반 병합

Merge

- 커밋의 이력을 모두 남길 때 사용한다.

 

B. 빨리감기 병합

Fast-forward Merge

- master 브랜치에서 분기한 시점이후, master 브랜치에 최신 커밋이 없을 때 가능하다.
- 충돌이 생기지 않고, 원래 하나였던 것처럼 병합된다. 

 

 

C. Squash 병합

Squash and Merge

- 빨리감기 병합과 같은 조건일 때 가능하다.

- 다른 점은 분기한 브랜치의 모든 커밋이 master 브랜치에 하나의 커밋으로 만들어진다는 것이다.

- 기능상 의미 있는 하나의 커밋만 남길 때 유용하다.

- 기능 단위로 묶어서 커밋할 수 있어서 변경사항을 추적하기 용이하다.

- 기능 단위로 사용하지 않을 경우, 변경사항에 대한 파악이 어렵다.

 

 

D. Rebase 병합

Rebase and Merge

- Squash 병합과 비슷하지만, 다른 점은 master 브랜치에 최신 커밋이 있어도 가능하며 하나의 커밋이 아니라, 빨리감기 병합처럼 그 뒤에 커밋들이 만들어진다.

- 기능에 대한 구분이 사라져, 커밋을 기능별로 관리할 필요가 생긴다.

---

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

브랜치 전략에 대해 살펴보기 전에, 브랜치를 하는 이유에 대해서 생각해보자.

A. 브랜치를 하는 이유는 무엇인가?

• 브랜치는 커밋한 내용을 '모듈화'하는 과정이라 생각하면 된다. 모듈화는 작은 단위로 만들어서 특정 기능만 담당하게끔 하는 것을 의미한다. 브랜치를 통해 커밋을 분기시키는 이유도 동일하다. 결국, 특정 기능만을 관리하고 유지보수를 더 수월하게 만들기 위함이다.
• 또한, 독립적으로 작업할 수 있으므로 여러 기능을 여러 사람이 병렬적으로 개발할 수 있다.

B. 브랜치 전략이 필요한 이유는 무엇인가?

전략이 필요한 이유는 효과적인 전투를 하기 위함이다. 전략이 있어야 효과적으로 자원들을 관리할 수 있다. 브랜치 전략도 마찬가지이다. 

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

 

1) 항상 유지되는 메인 브랜치

- master, develop

 

2) 일정 기간 동안만 유지되는 보조 브랜치들

- feature, release, hotfix

 

master : 제품으로 출시될 수 있는 브랜치 develop :다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

 

 

 

 

C. Git Flow 전략 항상 좋기만 할까?

https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

 

• 우선, 항상 좋기만 한 것은 어디에도 없다!
• Git Flow는 명시적으로 버전관리가 필요한 모바일 어플리케이션, 오픈소스 라이브러리/프레임워크 같은 프로젝트에 적합하다. 브랜치 전략을 알아보기 위해, 살펴본 우아한형제들 기술 블로그(https://techblog.woowahan.com/2553/) 역시 안드로이드 앱 개발팀이다.
• 웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하게 된다. 그렇기에 여러 버전을 병렬적으로 지원할 필요가 없을 뿐더러, 웹 어플리케이션은 하루에 몇번이고 릴리즈될 수 있다. 이런 이유에서 웹 어플리케이션 개발에서 Git Flow는 적합하지 않다고 말할 수 있다.
• 규칙을 따르면 안전하다고 말할 수 있지만, 많은 사람이 참여할수록 필연적으로 실수하고 헤매게 된다.

이에 대해, Vincent  Driessen은 Github Flow를 추천한다.

 

D. GitHub Flow에 대한 간략한 소개

이름 그대로 Github 환경에서 사용하기 적합한 브랜치 전략이다. 또한 자동화를 적극 활용하기도 한다. 핵심 브랜치는 두 개이다.

1. Main 브랜치
   항상 Stable한 상태여야 한다. 즉, 모든 커밋이 언제든 배포하더라도 문제가 없어야 하고, 새로운 브랜치를 생성해도 문제가 없어야 한다. Github Flow가 강제하는 유일한 사항이다.
   
   
2. Topic 브랜치
   - 새로운 기능을 개발 할 때 사용하는 브랜치
   - 이때, Topic 브랜치 이름은 어떤 기능에 대한 것인지 명확하게 네이밍해야 한다.

E. Git Flow와 GitHub Flow 중 어떤 전략을 사용하면 좋을까?

• Git Flow는 많은 브랜치를 관리하기에 복잡성을 갖고 있다. 그렇기에 빠르게 배포해야 하는 경우, 유연성이 떨어질 수밖에 없다. 그러나 그만큼 안정성과 버전 관리 및 롤백 면에서 체계적인 운영이 가능하다.
  
  
• GitHub Flow는 브랜치가 두 개인 까닭에 master 브랜치로 merge 될 위험성을 갖고 있다. 그러나 그만크 단순하고 빠르게 기능을 테스트하고 배포할 수 있기 때문에, 환경의 구분이 명확하지 않고 작은 규모의 프로젝트에 적합한 전략이다.

---

참고 자료

우아한형제들 기술 블로그(우린 Git-flow를 사용하고 있어요)
https://techblog.woowahan.com/2553/

브랜치 전략에 대한 글
https://nvie.com/posts/a-successful-git-branching-model/ 

 

git-flow에 대한 이슈와 GitHub Flow

https://githubflow.github.io/

 

Git Flow 와 GitHub Flow 중 어떤 전략을 사용해야 할까?

https://devocean.sk.com/blog/techBoardDetail.do?ID=165571&boardType=techBlog