두 브랜치의 커밋을 합칠 때 사용할 수 있는 방법으로 git merge와 git rebase가 있습니다. 오늘은 이 둘의 차이에 대해 살펴보도록 하겠습니다.
우선 설명을 위해 master 브랜치와 develop 브랜치를 만들겠습니다. master 브랜치에서 develop 브랜치를 분기한 이후에 master 브랜치에서는 m1, m2이라는 커밋이 있었고, develop 브랜치에서는 d1, d2이라는 커밋이 있었다고 하겠습니다. 이제 master 브랜치에서 develop 브랜치를 당겨와서 합치도록 하겠습니다.
git merge
먼저 git merge입니다. master 브랜치에서 아래 명령을 실행합니다.
git merge develop
하나로 합쳐진 것을 확인할 수 있습니다. 분기되었던 흔적이 그대로 남아있습니다.
git rebase
이번에는 git rebase를 해보겠습니다. rebase는 base를 다시 설정한다는 뜻입니다.
git rebase develop
git rebase는 git merge와 다르게 분기되었던 것이 사라지고, 마치 하나의 브랜치에서 작업이 이뤄진 것처럼 보이게 해줍니다. d1, d2를 먼저 커밋으로 인정한 후에 rebase를 하는 주체인 master 브랜치의 커밋들을 뒤에 이어줍니다. 그리고 여기서 중요한 것 사실은 rebase 명령 후에 m1, m2는 아까 커밋한 것이 아니라 rebase 과정 중에서 새롭게 커밋된 것입니다. 커밋 해시를 살펴보면 다릅니다.
뭐가 더 나은가?
커밋 히스토리를 깔끔하게 하려면 git rebase가 좋지만, 분기와 병합 이력도 남기고 싶다면 git merge가 필수적입니다. 그리고 rebase는 원격 저장소에 올라간 커밋을 rebase를 할 때는 문제를 일으킬 수 있습니다. 같은 내용의 커밋이 중복해서 히스토리에 남을 가능성이 있습니다. 따라서, rebase는 로컬 브랜치 간에 코드를 병합할 때 히스토리를 깔끔하게 하기 위한 목적에 한정해서 쓰는 것이 안전하다고 볼 수 있습니다.
참고자료
[1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing
'DevOps > git' 카테고리의 다른 글
| [gitlab] gitlab-ci로 ec2에 jar 배포를 위해 SSH 키 생성하고 세팅하는 방법 (0) | 2024.06.10 |
|---|---|
| [git] 단 하나의 커밋 존재할 때 커밋 취소하는 방법 (0) | 2023.10.17 |
| [git] 가장 최근 커밋 메시지 수정하기 (0) | 2023.10.11 |
| [gitlab] 레포지토리 디폴트 브랜치 설정하는 방법 (0) | 2023.09.26 |
| [git] .DS_Store 파일은 뭘까? (0) | 2023.09.14 |
| [git] master 브랜치로 merge하기 (0) | 2023.06.21 |
| [git] feature 브랜치 생명 주기(life cycle) 정리 (0) | 2023.06.20 |
| [git] 리모트 브랜치와 로컬 브랜치 커밋 비교하는 방법 (0) | 2023.06.14 |