Git - branch merge 방법 / Git Flow 브랜치 전략

branch merge 방법

 

1. merge

: main 과 branch 를 공통 부모로 하는 새로운 커밋이 생긴다

2. squash merging

: branch 의 커밋 히스토리가 main 에 합쳐진다

브랜치 커밋 히스토리가 없어지고 하나의 커밋으로 병합된다

3. rebase merging : branch의 base를 main 으로 재설정 > commit 아이디가 변경된다

 

병합 방법	merge	squash merging	rebase merging
새로운 커밋이 생기는가?	O	X 상태만 변경됨	X
병합된 main 브랜치에서 branch의 커밋 히스토리가 유지되는가?	O	X	O
브랜치가 남아있는가?	O	O	X
커맨드	git merge branch	git merge branch --squash	git switch 또는 checkout branch git rebase

---

Git flow 전략 : 브랜치 생성에 규칙을 만들어 협업이 원활하게함

브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다.

 

feature > develop > release > hotfix > master

             보조 브랜치                  메인 브랜치

 

Git-flow 브랜치 구조

• master : 라이브 서버에 제품으로 출시되는 브랜치. 배포 가능한 상태만을 관리
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치. 다음에 배포할 것을 개발
• feature : 추가 기능 개발 브랜치. develop 브랜치에서 나와서 develop브랜치로 들어간다.
• release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다. 배포를 위한 최종적인 버그 수정
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.  배포한 버전에서 긴급하게 수정

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 

보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.

즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취한다.

보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

---

GitHub Flow : Git flow는 GitHub에 적용하기에는 복잡하기때문에 만들어진 새로운 깃 관리 방식

 

자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.

Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.

 

흐름

1. 브랜치 생성

2. 개발 & 커밋 & 푸쉬

3. PR 생성

4. 리뷰 & 토의

5. 테스트

6. 최종 Merge

 

 

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow