🔥 문제
어제 깃 리베이스로 인해 한 번
cherry-pick
으로 대수술을 거쳤다.문제는 발생할 수 있지만, 가장 중요한 것은, 문제를 재발시키지 않는 것이다.
따라서 이를 기록으로 남기고자 한다.
상황
우리는 작업 도중, 급하게 변경한 사항을 실제로 모든 작업단에서 통일시켜야 하는 상황이 발생했다.
따라서 이를 풀 리베이스로 당겨야 했는데, 당긴 결과 기존 작업 커밋 내역과, 리베이스 할 때의 커밋 내역이 혼재해버리는 상황이 발생했다.
따라서, 이를 해결해야 했다.
⭐ 해결 방법
원인은 부모 브랜치에서
git pull --rebase
를 하지 않았던 것이었다.리베이스를 한다는 것은, 결국 현재 작업하고 있는
HEAD
를 목표로 하는 브랜치의 베이스로 가도록 하는 것이다.이때, 부모 브랜치에서
git pull —rebase
를 진행했다면 문제가 발생하지 않는다. 기존 부모 브랜치에 있었던 내역들을 한 번에 리베이스시키기 때문이다,하지만 현재 작업 브랜치에서
rebase
를 시켜버렸기 때문에, 결과적으로 커밋 내역이 꼬여버린 것이다.실제 적용 예시
현재 커밋이 다음과 같다. 현재 많은 브랜치가 다음
develop
브랜치로부터 뻗어나가고 있다.
우선 첫째, 가장 중요한 것 - 항상 브랜치는 develop
에서 따와져야 한다.
로컬 디벨롭에서 따오는 것이 가장 중요하다.
디벨롭은 →
origin/develop
에 리베이스했기 때문에 최신 상태를 유지할 수 있기 때문이다.pull —rebase로 하여 branch
를 원격 branch에 리베이스하며 병합하기.
다음과 같이 먼저 부모인
develop
에 갔는지 체크하고 이를 pull --rebase
하여 origin/develop
으로 전달한다.
그렇다면,
rebase
가 develop
이 원격에 잘 적용된 것을 확인할 수 있다.
작업 브랜치도 리베이스하기
따라서 develop이 움직였다면, 여기서 같이 작업하던 브랜치들도 리베이스를 진행한다.
git switch <이전 develop에 있었던 작업 브랜치> git rebase origin/develop

잘 적용이 됐음을 확인할 수 있다.
배운 점
- 리베이스는 항상 최신화된 부모 브랜치(develop)에서 할 것을 권장한다.
- 아래에서 위에 있는 브랜치로 갈 때는 안전하게
pull --rebase
로 하자.
- 부모 브랜치만 리베이스할 것이 아닌, 작업 브랜치도 함께 rebase해야 깔끔하게 관리가 가능하다.
👏🏻 참고자료
깃 대마왕 도큐멘철의 깃 병법 제 4장 3절