Branch merge란?
현재 branch에서 다른 branch를 합칠 때 사용합니다.
branch 를 merge 하는 방법에는 merge, squash, rebase 3가지가 있습니다.
특정 branch로 합치게 해달라고 요청하는 pr(pull request)에도 merge 방법 중 하나를 선택할 수 있습니다.
Commit은 쌓여 커밋 히스토리를 만드는데 이 히스토리로 저장소 내에 무슨 일이 일어났는지 알 수있게 되지만 이 브랜치들이 합쳐지며 순서나 과정들을 제대로 알아보지 못 할 경우를 대비하기 위한 전략들입니다.
Merge commit
기본 merge라고도 불리며, 두 브랜치를 병합할 때 전에 생성된 커밋과 히스토리를 유지하면서 병합을 한다는 특징이 있습니다. 모든 커밋과 분기했던 branch 히스토리가 남으며 이 부분에서 장점과 단점들이 같이 존재합니다.
Squash and merge
squash 는 병합할 브랜치의 커밋 메시지들을 합쳐 하나의 커밋 메시지를 만들어 merge 합니다.
그래서 여러 개의 커밋 메시지를 한 개의 커밋 메시지로 합치게 되어 커밋 히스토리를 간결하게 만들 수 있지만,
개발자 브랜치에서 추후에 어떤 내용들이 변경되었는 지의 정보를 잃을 수 있어 알기 어렵다는 단점이 있습니다.
Rebase and merge
rebase 는 현재 브랜치에 있는 커밋들이 재베이스할 브랜치의 새로운 커밋 아이디를 가진 커밋으로 새로 추가됩니다.
그래서 히스토리의 Base를 직접 옮기는 방식으로 깔끔하게 유지되지만, 코드가 충돌될 가능성이 높고 어느 시점에 merge가 되었는지 파악하기 어렵다는 단점이 있습니다.
깃 브랜치 전략(Git Branch Strategy)
Git에서는 동시에 여러 작업을 할 수 있게 Branch를 사용하는데, 작업 영역을 분리하여 수정하고 관리하고 원래 버전과 합칠 수도 있습니다. 이런 Git의 Branch를 관리하는 전략들을 Git Branch Strategy(깃 브랜치 전략)이라고 합니다!
조금 더 자세히 보자면 PR과정과 add, commit동작들을 합니다.
1. PR(Pull Request) 과정
저장소 clone → 브랜치 생성, 이동 → 소스코드 작성, 변경 → 변경한 내용을 git add로 저장 → git commit으로 변경 사항 저장 → git push하여 원격 저장소에 소스코드 올림 → Pull Request 전송
2. add, commit 동작
add : git에 현재 commit된 버전과 다른 수정 파일이 있음을 알려주는 동작 (staging area에 올림)
commit : git에 변경된 파일이 있음을 명시하는 동작 (staging area에 있는 것들 커밋으로 남기기)
Git Branch 전략의 종류
- Git Flow
- Github Flow
- Gitlab Flow
Git Flow
깃 브랜치 전략은 크게 Git Flow, Github Flow, Fitlab Flow가 있는데 그 중에서 Git Flow는 대표적으로 많은 회사와 팀에서 사용하고 있는 전략이며 이것에 관하여 자세히 알아보려 합니다.
Gitflow에는 5가지 브랜치가 존재합니다.
- master : 기준이 되는 브랜치로 제품으로 출시할 수 있는 브랜치
- develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
- feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
- release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
- hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치
특징
- 용도에 맞게 브랜치를 분리해 사용합니다. (feature > develop > release > hotfix > master) (병합 순서는 앞에서부터 뒤로 병합하며, develop와 master 브랜치는 중심이 되는 브랜치라서 무조건 존재해야 합니다.)
- 명확한 릴리즈 버전 관리를 위한 브랜치를 따로 관리하고 있어서 버전에 대한 유지보수가 뛰어납니다.
- 기능 개발 사이의 충돌을 최소화 할 수 있습니다.
- 명확한 배포 기간과 주기적인 버전이 정해진 프로젝트에 적합합니다.
과정
- master에서 develop을 분기
- 개발자들은 develop 브랜치에 자유롭게 커밋
- 기능 구현이 있는 경우 develop에서 feature-* 브랜치를 분기
- 배포를 준비하기 위해 develop에서 release-* 브랜치를 분기
- 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 수정 및 반영
- 테스트가 완료되면 release 브랜치를 master와 develop에 merge