TL;DR
git pull --rebase origin dev- conflicts 를 해결한다!
git push -f- PR 페이지에서 Rebase and Merge
왜 rebase를 해야하나?
그동안의 나는?
→ dev로부터 여러 분기가 생겼고, 작업 완료후 그냥 다 Merge만 해왔음!
merge
이런 히스토리가 됨! c3 가 다른 가지로부터 남고 머지 커밋이 생기는거
rebase를 사용하면?
checkout experiment && rebase master
==git rebase master experiment같음
이렇게 실행하면 왼쪽과 같이 C3이 리베이스 되어 기존 베이스 브랜치에 붙음! (복사되는것임!!)
그리고 오른쪽처럼 master브랜치를 fast-forward하면 하나의 히스토리 완성!
그래서 장점은?
- 커밋 히스토리 깔끔! 여러 브랜치로 분기해서 작업했었지만 히스토리상 dev에서 순차적으로 이어서 한거 같은!
하지만 단점은?
- 내 사용 경험상, base 브랜치와 작업 브랜치 사이 쌓인 커밋 마다 마다 충돌해결을 다해야함…
rebase conflict
위에 말한 것처럼, base 브랜치와 작업 브랜치 사이 쌓인 커밋들에서 충돌이 생기면 하나하나 다 해결을 해야한다. 해보자!
Merge conflict가 나면 마주하는 모양
둘중 하나를 선택해야하나? 뭐를 선택해야 하나?
나의 경험으로 내린 결론은 최종으로 반영될 코드이다!
내가 수정한 부분이 베이스 브랜치에서도 변경되었을 경우 충돌이 날텐데, 각각이 새로운 버전일테니 잘 고려해야한다!
base에서 apple 이었는데
b1브랜치에서 apple good으로 수정해서 머지했다.
b2브랜치에서 apple을 apple is good으로 수정해서 머지하려고 했더니 충돌이 나겠지?
현재 베이스는 apple good인 상태일테니, 이 버전과 b2브랜치의 버전 중 최종으로 남을 것을 선택해야한다!
--> 이런 충돌이 많아지면 일일이 판단을 해야하는게 쉽지 않을 거라고 생각한다. 그래서 base에 변경사항이 생기면 최대한 빠르게 rebase를 하는게 좋다고 느꼈다. 실제로 프로젝트에서도 이 전략(?)을 사용했다.
참고
https://unordinarydays.tistory.com/161 💛위의 그림 출처
https://git-scm.com/docs/git-rebase
자료
https://velog.io/@yellowtoast/Git-완전정복-Git-conflict-충돌을-해결하는-방법!
