git rebase와 git merge
Git 에서 한 브랜치에서 다른 브랜치로 합치는 방법으로 Rebase와 Merge가 있다.
사실 브랜치를 합치는 결과를 나온다는 것은 동일한데, 두 방법의 차이점과 각각 적용하는 상황에 대해 알아보려고 한다.
아래 공식 레퍼런스를 참고하였다.
1. git merge 란?
한 브랜치에 다른 브랜치를 합치는 작업으로 merge를 하면 각 브랜치의 히스토리가 모두 보존된다.
merge는 Fast-forward와 3-way Merge로 두 가지 방식이 있다.
- Fast-forward : C4가 C2에 기반했기 때문에 별도의 Merge 과정없이 포인트만 최신 커밋으로 옮긴다.

- 3-way Merge : Merge 커밋 생성한다.
iss53
에 git merge master
를 통해 합치거나, iss53
이 master
에 Merge 할 수 있는 수준이 될 때까지 기다렸다가 Merge 하면 합쳐진다
- C5의 조상이 C4가 아니므로 ‘Fast-forward’ 방식으로 Merge 하지 않는다.
- 각 브랜치가 가리키는 커밋(C4, C5)과 공통 조상(C2)을 사용하여 3-way Merge를 진행한다.
- 3-way Merge의 결과를 별도의 커밋으로 생성하고 해당 브랜치가 그 커밋을 가리키도록 이동시킨다.

2. git rebase 란?
브랜치의 베이스를 재설정하여 다시 커밋을 재적용하는 작업이다. C4에서 변경된 사항을 Patch로 만들고 이를 다시 C3에 적용 시키는 방식이다.


3. 차이점
- Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다
- Merge는 히스토리를 보존하고, 리베이스는 히스토리를 재작성한다.
- Rebase가 좀 더 깨끗한 히스토리를 만든다.
- 일을 병렬로 처리해도 Rebase는 선형 형태로 모든 작업이 차례대로 수행된 것처럼 보인다.
- Rebase는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고, Merge 는 두 브랜치의 최종결과만 가지고 합친다.

4. rebase의 위험성
- remote 등 어딘가에 push로 내보낸 커밋에 대해서는 절대 Rebase하지 말아야 한다.
- 다른 팀원이 이미 push 된 작업을 pull 하여 작업하고 있다면 팀원은 다시 merge 작업을 진행해야 하기 때문이다.
- 또한, 팀원이 merge 한 작업을 다시 pull 로 받게 되면 코드가 엉망이 되어버릴 수 있다.
- rebase는 히스토리를 재작성하므로 데이터 손실이 일어날 수 있다.
- rebase는 항상 새로운 커밋이 생성되고 이전 커밋은 히스토리에서 삭제된다.
- 충돌 가능성
- merge의 경우 각 브랜치의 마지막 작업만 가지고 병합하기 때문에 한 번에 처리할 수 있지만, rebase의 경우 여러 번의 패치 작업을 진행하기 때문에 충돌 문제를 여러 번 해결해야 할 수도 있다.
5. Rebase를 사용하면 좋은 경우
- 혼자 또는 작은 규모의 팀인 경우
- push한 커밋 내역은 다른 사람들에게 영향을 미치기 때문에 주의해야 한다.
- 전체 팀 프로젝트 관리를 위해서는 전체 기록을 보관하는 것이 좋다.
- 로컬에서 커밋 히스토리를 정리하는 경우
6. Merge를 사용하면 좋은 경우
- 큰 규모의 작업인 경우
- 모든 작업에 대한 기록이 보존되므로 관리 및 추적이 쉽다.
7. 결론
rebase와 merge는 브랜치를 합치는 것은 같다. 히스토리를 정리하고 싶다면 rebase를 사용하면 되겠지만, 모든 작업 내용을 보존할 때에는 merge가 좋은 방법을 것이다.
또 작업 규모에 따라 절대적으로 merge와 rebase 사용 여부가 결정되는 것은 아니다. 작업 과정과 필요성에 따라 merge와 rebase를 적절히 사용하면 좋을 것이다.