Rebase vs Merge
- 둘 다 분기된 브랜치를 하나로 합칠 때 사용하는 방법
공통 상황
- master에서 분기된 develop 존재
- 각 기능 개발을 위해 develop에서 feature/test 브랜치를 생성
- feature/test 브랜치에 commit 1,2,3이 커밋된 상황
- 그 사이에 develop 브랜치에 develop commit 1이 추가 커밋된 상황
- develop 브랜치의
develop commit 1의 작업 내용과 feature/test 브랜치의commit 2는 같은 소스를 작업 (소스 충돌)
Merge
- 병합하고자 하는 브랜치의 변경사항을 현재의 브랜치의 최신 커밋 이력으로 남긴다.
Step #1
- 초기 작업 상황
- feature/test의 작업이 끝내고 develop으로 반영해야한다.
Step #2
- feature/test의 base가 된 develop 브랜치에서 추가 작업(develop commit 1)이 있었음
- develop의 추가 작업 내용을 feature/test에 반영하기 위해
merge develop into feature/test실행 - 충돌나는 작업이 생김
Step #3
- 충돌 해결
- 충돌 나는 소스를 적절히 수정 후 푸쉬
Step #4
- 머지가 완료된 브랜치 현황
- 즉 병합하고자 하는 브랜치(develop)의 변경 사항들이 현재 브랜치(feature/test)의 최신 커밋 이력으로 남았다.
- Merge branch ‘develop’ into ‘feature/test’
Rebase
- 분기되어 빠져나온 브랜치(feature/test)의 base 브랜치(develop)를 다시 재설정(rebase)한다
- 역시 말로만 표현하려니 어렵다..
Step #1
- 초기 작업 상황
- feature/test의 작업이 끝내고 develop으로 반영해야한다.
Step #2
- feature/test의 base가 된 develop 브랜치에서 추가 작업(develop commit 1)이 있었음
- develop의 추가 작업 내용을 feature/test에 반영하기 위해
rebase feature/test onto develop실행 - 아까와 마찬가지로 충돌나는 작업이 생김
Step #3
- 충돌 해결 후 머지하면 위와 같이 base(develop)를 최신 상태로 재설정하여 그 이후 feature/test 브랜치가 분기된 것 처럼 나온다
장/단점
Merge- 편하다 ( 개인적인 생각.. )
- 충돌 해결을 하기 직관적이다 ( 최종 이력이 생겼을 때 수정하면 된다 )
- 단 커밋 이력이 지저분 해진다
Rebase- 커밋 이력이 깔끔하게 남는다
- 의미없는 커밋이 없어짐 ( Merge ….. )
- 충돌 해결이 어렵다.. ( 각 충돌난 이력마다 처리해줘야한다 )
- 언제 어떤 것을 사용할까?
- 이제부턴 개인적인 생각
- base로 부터 분기가 된지 오래됐으면 merge를 쓰는게 정신 건강에 좋은 것 같다.. (rebase는 충돌 수정을 하나씩..)
일반적으로 rebase를 우선순위로 생각하자 ( 커밋 이력이 깔끔한 장점이 명확 )- 만약 로컬에서 작업중인 feature가 origin에 push 됐다면 rebase하면 안된다.
rebase는 base를 다시 맞추는 것이기 때문에 commit history hash 값이 바뀐다- 만약 origin에 push된 feature가 있는데 develop을 rebase 후 push 하려고하면 아래와 같은 상황이 된다
