git rebase에 대하여
원격저장소의 데이터를 가져올 때
git pull을 할 것인가.
아니면 git fetch후 git rebase를 할 것인가를 고민한다.
git pull은 git fetch와 git merge가 간략화 된 것이다.
그럼 git merge와 git rebase의 차이점을 알아보자
merge는 브랜치를 병합하는 것이고,
rebase는 베이스를 재정의하여 커밋 히스토리를 조작하는 것이다.
Merge
master에서 develop branch가 파생되어서 작업이 진행된다.
이때 merge가 일어나면
merge commit이 하나 생성이 되고
두 브랜치가 병합되는 것을 볼 수 가 있다.
Rebase
rebase도 위 처럼 동일하게 작업되다가 rebase가 발생하면
master branch에 있던 커밋 중 최신 커밋이 develop 브랜치의 새로운 베이스로 재정의가 된다.
그리고 develop branch에 쌓여있던 커밋들이
재정의된 Base에 순차적으로 새롭게 커밋이 쌓이게 된다.
Merge의 특징
충돌이 일어날 경우 한번에 해결이 가능하다.
만약 merge를 하던 도중 충돌이 일어나면
merge 커밋을 날리기 이전에 모든 충돌을 다 한 번에 해결하고
하나의 커밋으로 충돌을 해결할 수 있습니다.
그리고 merge는 어떤 브랜치에서 merge가 발생했는지를 알 수 있습니다.
그래서 이 merge 때문에 커밋이 남게되고,
만약 브랜치와 커밋이 많아지게 되면
깃 히스토리가 복잡해져서 알아보기 어려워질 수도 있다
Rebase의 특징
merge와 다르게 충돌이 일어난 부분부터 하나씩 모든 충돌을 해결해야한다.
그래서 재정의된 Base 이후부터 충돌이 일어나게 된다면
하나씩 충돌을 해결하고,
또 충돌이 일어나면 그 다음 충돌을 해결해야한다.
한번에 충돌을 해결하지 못하고 충돌이 일어날 때마다 다 충돌을 해결해 주어야 한다.
rebase는 하나의 브랜치로 커밋 히스토리 정리가 가능하다.
rebase되면 마치 브랜치가 하나인 것처럼 깃 히스토리가 정리된다.
Rebase사용 시 주의할점
- 원격 저장소에 올라간 커밋을 Rebase하는 경우
1. feature 1에서 기능을 완성 후 master 브랜치에 머지를 해서 동일해진다.
2. feature 2에서 master 브랜치에서 pull 받게 되면 위처럼 형성된다.
3. 이제 feature 2와 feature 3이 모두 기능이 완성되고 master에 머지를 해야한다.
4. feature2와 feature 3을 각각 머지하는게 번거로워 feature 2에서 feature 3에 rebase를 수행했다.
5. 그럼 feature 3의 최신 커밋이 feature 2의 새로운 베이스로 재정의가 되고, feature 2에 있던 커밋들이 새로 정의된 베이스 위로 새로이 쌓이게 된다.
6. 그럼 이와같이 변경되는데 문제가 발생한다.
7. 이전 커밋들과 비교했을 때 동일한 커밋인데도 불구하고 hash값이 1과2에서 4와 5로 바뀌게 된다.
8. 그래서 이를 master에 머지시키게 되면 다음과 같은일이 발생한다.
9. 분명 hash값 1을 가진 커밋과 hash 값 5를 가진 커밋은 같은 커밋인데도 불구하고, 중복되어서 올라가 있는 것을 확인할 수 있습니다.
10. 이 문제가 발생하는 이유는 master에 이미 올라가있던 커밋을 1번 커밋을 받아와 reabse하는 과정에서 이 커밋이 새로운 해시값을 가지고 새롭게 생성되어서 다시 master에 올라갔기 때문입니다.
그렇기 때문에 원격 저장소에 올라간 커밋을 rebase하는 것을 권장하지 않는다.
https://www.youtube.com/watch?v=6nc_0-HWZXU&t=284s
출처