GitLens로 쉽게 git rebase 하기

Tech

rebase가 필요했던 상황

작업 내용작업한 브랜치머지하려는 브랜치
피드 목록 조회 API 연결feat/Adevelop
피드 개수 보여주는 부분 추가feat/Bfeat/A
masonry 레이아웃 적용feat/Cfeat/B

develop -> feat/A -> feat/B -> feat/C 순서로 브랜치를 생성하고 3개의 PR을 올렸습니다.

develop  
└── feat/A  
    └── feat/B  
        └── feat/C

뒤에서부터 차례대로 머지하면 된다고 생각할 수 있겠지만, 모든 PR의 코드 리뷰가 끝나지 않았기 때문에 순서대로 머지할 수 없었습니다. 그리고 다른 팀원의 작업을 위해서 feat/A 브랜치만 먼저 develop으로 머지되어야 하는 상황이었습니다. 이 상황에서 팀원의 도움으로 rebase를 적용해 커밋을 깔끔하게 관리할 수 있었습니다. 앞으로도 종종 쓰일 것 같아 블로그에 정리해 보고자 합니다.

rebase 순서

먼저 develop으로 머지되어야 하는 feat/A 브랜치의 PR부터 squash merge를 진행했습니다. feat/A가 squash merge되면서 develop에 새로운 단일 커밋이 생성되었는데, feat/B에 있던 feat/A의 개별 커밋들이 별도의 커밋으로 인식되면서 feat/B 브랜치의 Commits 수가 늘어났습니다.

이 문제를 해결하기 위해 rebase를 진행했습니다.

  1. feat/A를 develop에 머지했으니 develop에서 git pull
  2. feat/B로 이동하도록 git switch feat/B
  3. 이동한 상태에서 develop 브랜치 기준으로 rebase를 진행 git rebase -i develop
  4. GitLens를 통해 feat/B PR에서 작업한 커밋만 남겨두고 나머지는 다 drop
    이때 GitLens extension을 설치하면 더 쉽게 drop이 가능합니다. VSCode Command Palette에서 GitLens: Enable Interactive Rebase Editor 설정이 필요합니다.
  5. git push -f로 force push하면 rebase 완료
    feat/B PR을 새로고침하니 Commits 수가 원래대로 줄어들었고, feat/C PR도 마찬가지로 rebase를 진행했습니다.

마치며

이렇게 rebase를 통해 브랜치 간의 의존성 문제를 깔끔하게 해결할 수 있었습니다. 특히 GitLens의 Interactive Rebase Editor를 사용하면 시각적으로 편하게 커밋을 정리할 수 있어 유용했습니다. 실제 개발에서는 이런 예상치 못한 상황들이 언제든 발생할 수 있기 때문에, 이번에 배운 방법을 잘 기억해두고 활용해야겠습니다.