기준이 되는 main 브랜치가 있음.
main을 기준으로 a 브랜치를 만들고 새로운 기능 추가.
그리고 readme의 상태.
main을 기준으로 b라는 또 다른 브랜치를 만들어 read me 수정. 이때 a 브랜치의 read me 3번 째줄과 충돌되는 내용을 작성.
a와 b 브랜치 모두 remote에 push 후 b 브랜치에서 a 브랜치를 기준으로 pull 받음. 그럼 read me의 내용이 겹치기 때문에 conflict 발생.
<aside> 💡 왜 삭제했을까?
</aside>
기준이 되는 main 브랜치가 있음.
main을 기준으로 a 브랜치를 만들고 새로운 기능 추가.
그리고 readme의 상태.
main을 기준으로 b라는 또 다른 브랜치를 만들어 read me 수정. 이때 a 브랜치의 read me 3번 째줄과 충돌되는 내용을 작성.
a와 b 브랜치 모두 remote에 push 후 b 브랜치에서 a 브랜치를 기준으로 pull 받음. 그럼 read me의 내용이 겹치기 때문에 conflict 발생.
이 때 staged changes를 discard 함. → a 브랜치 작업 내용 삭제
changes를 discard하면 작업 내용이 사라지는 것이 아닌 merge가 취소된다고 생각함. 하지만 실제론 충돌이 되지 않고 merge가 이뤄진 상태였고 이때 changes를 discard하면 코드가 제거됨.
<aside> 💡 그렇다면 rebase는 왜 이 현상을 예방할 수 있을까?
</aside>
pull은 fetch와 merge의 과정을 한 번에 처리하는 것인데, 이 때 기준 브랜치가 내 현재 브랜치 b를 기준으로 merge를 실행함. 그래서 충돌이 났을 때 current change에는 b 브랜치 내용이, incomming change로 a 브랜치 내용이 존재함. 마찬가지로 b 브랜치에서 a 브랜치 내용이 새로운 changes에 있는 것임.
rebase를 하면 기준으로 설정한 브랜치를 기준으로 로컬에 있는 commit 내역들을 새로 쌓음. 즉, base를 바꾸는 작업을 실행함. pull이 아닌 git rebase origin/feat/a를 실행하면 다음과 같음.
a 브랜치 작업 내용을 기준으로 b 브랜치의 작업 내역을 새로 commit함.
a 브랜치에서 작성된 새로운 기능도 changes에 있지 않고 이미 반영된 상태.
이처럼 기존에 작성된 a 브랜치를 기준으로 base를 쌓아야 적어도 기존 코드에 대해 보호할 수 있는 확률이 높아짐.