rebase가 필요했던 상황
| 작업 내용 | 작업한 브랜치 | 머지하려는 브랜치 |
|---|---|---|
| 피드 목록 조회 API 연결 | feat/#428 | develop |
| 피드 개수 보여주는 부분 추가 | feat/#448 | feat/#428 |
| masonry 레이아웃 적용 | feat/#447 | feat/#448 |
develop -> feat/#428 -> feat/#448 -> feat/#447 순서로 브랜치를 생성하고 3개의 PR을 올렸습니다.
(develop에서 feat/#428 브랜치를 파고, feat/#428에서 feat/#448 브랜치를 파고, ...)
그럼 뒤에서부터 차례대로 머지하면 되는 거 아니냐고 생각할 수 있겠지만,
모든 PR의 코드 리뷰가 끝나지 않았기 때문에 순서대로 머지할 수 없었고,
다른 팀원의 작업을 위해서 feat/#428 브랜치만 develop으로 머지되어야 하는 상황이었습니다.
이 상황에서 팀원의 도움으로 rebase를 적용해 커밋을 깔끔하게 관리할 수 있었습니다. 앞으로도 종종 작업에 쓰일 것 같아 블로그에 정리해 보고자 합니다.
rebase 순서
피드 목록 조회 API 연결 PR(1번 PR)부터 squash merge를 했습니다.
1번 PR이 머지된 이후에는 1번 PR에서 작업했던 커밋들이 2번 PR에 포함되어 Commits 부분의 숫자가 늘어났습니다.
이 문제를 해결하기 위해 rebase를 진행했습니다.
- 1번 PR을 develop에 머지했으니까 develop 브랜치에서
git pull - 2번 PR 브랜치로 이동
git switch feat/#448 - 이동한 상태에서 develop 브랜치 기준으로 rebase를 진행
git rebase -i develop - GitLens를 통해 2번 PR에서 작업한 커밋한 남겨두고 나머지는 다 drop
GitLens extension을 설치하면 drop을 더 쉽게 할 수 있습니다.
VSCode Command Palette에서 GitLens: Enable Interactive Rebase Editor 설정이 필요합니다.
git push -f로 force push하면 rebase 완료
2번 PR에 가서 새로고침하니 Commits 부분의 숫자가 줄어든 것을 확인할 수 있었습니다.
3번 PR도 마찬가지로 rebase를 진행해 정리를 마쳤습니다.