Branch Merge
여러 개발자들이 모여 협업하는 경우, 각자 branch에서 맡은 기능에 대한 개발을 진행하고 개발이 완료되면 main과 같은 base 브랜치에 merge한 후 하나가 된 base의 코드를 서버에 배포하는 과정을 거치게 됨
Merge
- 두 개 이상의 개발 히스토리를 하나로 합치는 작업이며, 커밋 이력을 모두 남길 때 사용
- 이 방식은 Fast-Forward와 3-way(Recursive)로 나뉨
// merge할 브랜치로 전환
$ git checkout main
// git merge [브랜치명] : 현 브랜치(main)에 해당 브랜치(newbranch)의 내용 병합
$ git merge newbranch- 단점
- 불필요한 merge commit 생성
- 복잡한 프로젝트 history
✅ Fast-Foward Merge
- 새로운 커밋이 생기는 게 아니라 단지 브랜치가 이동하게 되는 머지
- 커밋 히스토리에서 같은 선(line) 상에 있는 브랜치를 머지할 때 Fast-Forward Merge가 이루어짐
- 브랜치를 비교할 필요가 없기 때문에 충돌이 발생할 일이 없음
✅ 3-way Merge (Recursive Merge)
- 3-way Merge는 base를 기준으로, 변화가 발생한 것을 Merge 결과로 채택함
- 3-way Merge가 완료되면 그 결과를 담고 있는 머지 커밋(merge commit)이 생성됨
- 3-way Merge는 ①, ②, ③ 세 가지 커밋을 기준으로 머지 커밋을 자동으로 생성함
① : 두 갈래로 갈라지기 전 공통 조상(base)이 되는 커밋
② : 한 브랜치가 가리키는 커밋
③ : 다른 브랜치가 가리키는 커밋
💡 mian브랜치와 newbranch브랜치를 머지했을 때 3-way Merge의 상황별 결과
| 경우 | base | main | newbranch | merge 결과 | |
|---|---|---|---|---|---|
| case1 | A | A | B | → | B |
| case2 | 1 | 2 | 1 | → | 2 |
| case3 | "hi" | (공백) | "hi" | → | (공백) |
| case4 | "bye" | "good" | "nice" | → | conflict 발생❗ |
Squash & Merge
- Squash는 여러개의 커밋을 하나의 커밋으로 합치는 것을 의미
Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash한 새로운 커밋을 base 브랜치에 추가하는 방식으로 병합- 커밋 히스토리를 깔끔하게 관리할 수 있지만, 병합된 브랜치의 히스토리를 추적할 수 없음
$ git checkout main
$ git merge --squash newbranch
$ git commit -m "squash & merge"
feature → develop 브랜치간 머지
feature 브랜치에서 기능을 개발하기 위한 지저분한 커밋 내역을 하나의 커밋으로 묶어 develop 브랜치에 병합하면서, develop 브랜치에는 기능 단위로 커밋이 추가되도록 정리할 수 있음
Rebase & Merge
- Base를 다시 설정한다는 의미
- 특정 브랜치의 베이스를 재설정하여 다시 커밋을 적용시켜 커밋 이력을 재정렬하는 작업을 의미
- Rebase는 브랜치를 병합시 Merge commit 기록을 남기지 않아 하나의 브랜치에서 작업한 것처럼 보임
// newbranch 브랜치로 전환
$ git checkout newbranch
// newbranch 브랜치를 main 브랜치 위로 rebase
// newbranch의 커밋들이 main 브랜치의 최신 커밋 위에 재배치
$ git rebase main
// 다시 main 브랜치로 전환
$ git checkout main
// main 브랜치에 newbranch 브랜치의 변경 사항을 병합
$ git merge newbranch
develop → main 브랜치간 머지
main 브랜치는 지금까지 작업한 모든 기능을 배포할 때 병합함
배움의 기록을 차곡차곡