[Git] merge 전략
merge전략
- branch1에서 공용브랜치(dev 또는 main)로 PR을 만든뒤 merge하는 상황
- merge/ rebase / squash
- merge
- merge는 두 브랜치의 변경 사항을 통합하는 기본적인 방법
- branch1에서 넘어온 commitID와 신규 merge commitID가 dev브랜치에 남게됨
- rebase
- 한 브랜치의 커밋을 다른 브랜치의 최신 커밋에 “재적용”(re-apply)하는 방식
- 이때에는 브랜치에서 넘어온 commitID가 아닌, 새로운 commitID가 발급되어 dev브랜치에 생성
- 장점
- merge commitID는 남지 않게 되어, 깔끔한 커밋관리
- 기존의 commit history는 유지
- 단점
- 이후에 branch1에서 다시 merge를 할때 충돌이 발생하므로, 사용하던 branch1은 더이상 사용이 어려움
- squash
- squash는 여러 커밋을 하나의 커밋으로 합치는 과정
- local repository에서 여러 커밋을 발생시켰을때 해당 커밋ID를 통합하여 하나의 commitID로 만들어 dev에는 하나의 commitID로만 이력 생성
- rebase, squash는 feature브랜치에서 공용브랜치로 merge할때에는 선택에 따라 가능. 다만, 기존의 feature브랜치는 재사용이 어려움에 유의
- dev와 main 브랜치는 서로 정기적으로 싱크를 맞춰야함 → 일반 merge 사용
⇒ dev 브랜치를 버릴 수는 없기 때문
- merge
실습 - merge
로컬 branch1에서 수정
origin/branch1으로 올림
pull requests - new pull request
main <- branch1으로 바꾸고 create pull request
merge
merge commit 생성됨
⇒ 일반 merge는 merge할 때마다 merge commit이 생성
실습 - squash merge
branch1에서 커밋 3개 만들기
push
세개의 커밋을 main에 일반 merge하면 보통 3+merge commit까지 총 네개 됨
create pull request
branch1의 현재 커밋 수 58
main의 현재 커밋 수 55
→ 여기서 일반 merge하면 main은 59가 될 것 (55+3+1)
squash merge를 해보자
main의 커밋 수가 56으로 예상과 다름
⇒ squash merge는 commit 내역을 제외하고 merge커밋만 만든다
→ 세 커밋ID를 통합하여 하나의 새로운 커밋ID로 만들어 merge하는 것 → 55+1
문제는 다시 pull request 해보면 merge안된 것처럼 커밋3개가 남아있음
→ branch 삭제 필요
branch 삭제 전 main으로 이동하고 삭제해야 함
origin의 branch1도 삭제
밀려있는 main도 pull해주기
반영 완료
실습 - rebase merge
main 브랜치에서 branch 생성
commit 2개 생성
push
create pull request
rebase merge
merge 커밋 없이 기존 커밋 내용만 추가됨
main으로 옮기고 rebase 삭제, pull origin main
다 최신화 완료
충돌상황 발생 시 merge
main 에서 branch1 생성
main에서 파일 수정
commit → push
branch1으로 변경
동일파일 수정 후 commit
여기서 충돌해결방법은 크게 두 가지
- git push origin branch1 → github로 main에서 branch1으로 pr → merge하면서 수정 가능
- pull을 통해 충돌 해결 후 push 및 pr, merge
2번을 해보자
git pull
충돌 해결 후 add, commit, push
create pull request 후 merge pull request
반영완료
사용한 branch 삭제해주기
branch1 삭제, origin/branch1도 삭제
git pull origin main으로 싱크맞추기