1. Cherry-pick vs Rebase

상황

  • 서비스의 개편이 시작되어 브랜치를 만들어 작업 한 후에 PR 을 날렸지만 베이스 브랜치에서 개발자 분들이 작업한 커밋이 푸쉬되어 있어서 PR 에 불필요한 커밋이 많이 포함 되어 있는 상황이었습니다.

해결책

  1. rebase
    • PR 에 불필요한 커밋이 많이 들어있게 되면 리뷰어가 리뷰를 하는데 어려움이 있기 때문에 최소한의 변경사항만 PR 하는 것이 업무 효율적으로 좋습니다. 그래서 기존PR 을 닫고 로컬에서 feature 브랜치에서 베이스 브랜치로 리베이스를 하게 되면 베이스 브랜치와 로컬의 feature브랜치간의 diff가 제가 작업한 커밋만 포함될 것이라 생각했습니다.
    • 하지만 중간에 너무 많은 커밋들과 충돌 사항들이 발생해서 리베이스를 하던 도중에 해결이 어려울 것 같아서 git rebase --abort로 중지 했습니다.
  2. cherry-pick
    • 기존에 작업하던 feature 브랜치에 작업한 커밋들이 포함되어 있으므로, 베이스 브랜치에서 새로운 feature/2 브랜치를 만든 후에 기존 feature 브랜치에서 작업한 작업 커밋들만 cherry-pick 해오면 베이스 브랜치 와의 diff 는 작업 커밋밖에 없을 것이라 생각했습니다.

결과

  • rebase 방법은 충돌 해결을 하다 이슈가 발생할 위험이 있어 중단하고 cherry-pick 으로 쉽게 해결을 할 수 있었는데, cherry-pick이 쉽게 될 수 있었던 것은 원격 브랜치와 제가 작업하며 추가한 내용이 충돌이 날 부분이 없었기 때문인 것 같습니다.
  • 리베이스를 하기 부담스러운 상황일 경우라면 새로운 브랜치를 만들고 나서 기존에 작업하던 커밋만 체리픽 해오는 것도 괜찮은 방법인 것 같습니다.
  • 이렇게 해결하고나면 기존 브랜치는 삭제해주어야합니다.