최근 팀 내에서 git rebase를 사용하다가 조그마한 사고가 있었다는 이야기를 듣고,
482번째 rebase에 대해 다시 검색하면서 알아보다가 이대론 안되겠다 싶어 글로 남겨 기억에 남기고자 한다.
아래 링크에 들어가면 볼 수 있는,
아주 아주 아주 이해하기 쉽게 잘 써놓은 블로그를 우연히 만나 거의 번역 수준으로만 작성할 예정 ㅎ;
다시 보니 Edureka라는 온라인 교육 플랫폼에서 운영하는 블로그 같다.
아래 글은 git이 어떻게 동작하는지, commit은 무엇이고 branch는 무엇인지부터 시작하지만,
그 부분은 건너 뛰고 git에서의 merging 이라는 개념부터 번역을 작성하려고 한다.
- Git Rebase vs Git Merge: Which is Better?
Merging이란?
Merging이란 개념은 보통 무언가를 하나의 개체로 합치는 것을 의미한다.
Git에서의 Merge 개념은 이러한 개념과 유사한데,
하나의 branch에서 발생한 변화들을 다른 branch에 포함시켜 다시 하나의 branch로 합치는 것을 의미한다.
위처럼 merging 전의 두 브랜치가 있다고 가정해보자.
파란색 commit들이 있는 branch가 master branch, 노란색 commit들이 있는 branch가 feature branch이다.
master의 '2' commit 이후에 feature를 만들어 'A', 'B' commit을 했고,
그 동안 master에서도 '3' commit 작업이 이루어졌다.
당연히 현재 master 입장에서는 'A', 'B' commit의 존재를 알 수 없고,
마찬가지로 feature 입장에서도 '3' commit의 존재를 알 수 없다.
그래서 master branch에 feature branch를 merge 하기 위해,
위처럼 feature를 master에 merge 하여 '4'라는 commit을 만들어냈다.
즉, 이 master의 '4'라는 commit은 '1', '2', '3', 'A', 'B'의 commit 정보들을 모두 담고 있다.
이와 같은 작업을 merging이라 하며,
git에서는 다음 두 가지 기능으로 merging 기능을 제공한다.
Git Merge란?
Git Merge는 branch들의 commit 이력들이 모두 온전하게 보존되는 merging 기법이다.
(이 부분이 Git Rebase와의 가장 큰 차이점)
다시 예제를 가져와, 위처럼 master branch에서 '1', '2', '3' commit이 발생하였고,
feature branch에서 'A', 'B' commit이 발생했다고 가정하자.
만약 우리가 master branch에서 Git Merge 작업을 진행한다면,
feature branch의 'A', 'B' commit은 그대로 master branch의 '4' commit에 반영되어 merge 될 것이다.
장점
- commit 로그들이 매우 철저하게 유지되기 때문에 어떻게, 언제 각 meger가 진행됐는지 온전한 히스토리를 파악하는 데에 큰 도움이 된다.
- 이 때문에 실수를 찾기 쉽고 해결하기도 용이하다.
단점
- 아래처럼 여러 branch들이 merge 되는 경우, 보기도 힘들고 다루기도 힘든 log history가 발생할 수 있다.
- 이 때문에 매우 user-friendly 하지 못하다.
Git Rebase란?
Git Merge와 매우 유사한 기능을 하는 Git Rebase는 merge 이후에 log들이 수정된다는 차이점이 있다.
Git Merge의 한계를 극복하기 위해 추가된 기능인데, log history를 직선 모양(linear)으로 만들어준다.
다시 위와 같은 예제를 가져와 보자.
master branch에서 '1', '2', '3' commit이 발생하였고, feature branch에서 'A', 'B' commit이 발생했다.
만약 우리가 master branch에서 Git Rebase 작업을 진행하면,
'A', 'B' commit들은 master branch의 '4', '5' commit으로 rebase 되고,
feature branch에는 더 이상 log가 존재하지 않게 된다.
장점
- log history가 직선 모양이다.
- 그 덕에 프로젝트를 쉽게 이동할 수 있다.
단점
- feature branch의 log history가 사라지기 때문에 target branch에 언제, 어떻게 commit들이 merge 되었는지 알 수가 없다.
Git Merve vs Git Rebase
| Git Merge | Git Rebase |
| branch들을 merge 할 수 있는 Git의 명령어이다. | 개발자들이 하나의 branch에서 다른 branch로 변화들을 통합시킬 수 있는 명령어이다. |
| merge 이후에도 log history가 온전한 형태로 남아있다. | merge 이후에 log history가 직선 형태로 수정된다. |
| feature branch의 모든 commit들이 master branch의 단 하나의 commit으로 병합된다. | feature branch의 모든 commit들이 master branch에 같은 수 만큼의 commit들로 rebase되어 추가된다. |
| target branch가 다른 사람들과 공유되는 branch인 경우 사용된다(ex. master branch). | target branch가 private branch인 경우 사용된다. |
언제 어느 것을 사용해야 할까?
위 그림에서 볼 수 있듯이,
Git Merge와는 다르게 Git Rebase에서는 'A', 'B' commit들이 어디서 언제 발생했는지 알기가 힘들다.
그러므로 commit log history를 다른 사람들 혹은 팀원들이 알 필요가 없는 경우,
즉, 다른 개발자들이 볼 필요가 없고 볼 수가 없는 개인적인 작업을 하는 branch에서는 Git Rebase를 사용하고,
target branch와 source branch 모두 다른 개발자들이 볼 수 있다면 Git Merge를 사용하자.
Git Merge와 Git Rebase를 함께 사용하는 방법
위처럼 master branch에 '1', '2', '3' commit들이 존재하고,
'A', 'B'라는 commit들이 존재하는 feature branch 1,
'C', 'D'라는 commit들이 존재하는 feature branch 2가 존재하고 있는 프로젝트를 가정해보자.
이러한 상황이 만들어진 원인은 다음과 같다.
- 개발자 대흉근은 master branch의 '2' commit 이후에 feature branch 1을 생성하여 개인적인 작업을 하고 있다.
- 본인이 만든 코드에 좀 더 실험을 해보고 싶어서 'A' commit 이후 feature branch 2를 생성했다.
- feature branch 2에서 'C', 'D' commit을 날려 실험을 성공적으로 마무리했다.
하지만 대흉근은 feature branch 2라는 private한 branch의 존재를 누구도 알 필요가 없다고 생각했기 때문에,
위처럼 feature branch 1에 feature branch 2를 rebase하는 작업을 진행했다.
이제 대흉근은 feature branch 1을 master branch에 merge하는 작업을 진행했고,
위와 같은 commit log history가 최종적으로 만들어졌다.
다음 날, 출근을 한 다른 개발자들이 master branch에서 pull 작업을 진행했고,
'feature branch 1에서 'A', 'B', 'C', 'D' commit이 만들어졌구나' 정도만 알 수 있게 된다.
이제 진짜 더이상 git rebase와 git merge의 차이에 대해 알아보지 않아도 될 것 같다 (ㅋㅋ).
그만큼 글 초반부에 언급했던 블로그가 굉장히 큰 도움이 되었다.
이 포스팅을 작성하면서,
회사에서 내가 작업한 branch를 master에 merge하면 왜 commit history가 지저분하게 나오는지 이해됐다..
끝!
'Study > Git' 카테고리의 다른 글
| [Git][Github] Repository Naming Convention이 있을까? (0) | 2021.08.25 |
|---|---|
| [Git] fatal: unable to access 'https://github.com/*/*.git/': The requested URL r (0) | 2021.08.15 |
| [Git] Repository 생성 후 Main -> Master 브랜치로 변경하기 (0) | 2021.08.08 |
