[GitHub] PR(풀리퀘) 작성 시, 이전의 다른 브랜치의 이슈가 따라오는 문제, stacked changes

  - 문제 상황  

PR commit history : 브랜치#52의 PR에 브랜치#20의 commit 내역이 따라온 상황

 

한 branch에서 작업하다가 PR 올린 상태

-> 이후 merge가 안된 상태(코드리뷰를 계속 받고 있다던지)로 다시 또 branch를 파서 작업하다가 develop에 PR을 올린 경우

 

브랜치 상태

 

하지만 원래 develop에서 branch를 생성하기에는 merge가 아직 안된 branch에서 작업한 코드가 필요한 경우 merge가 되기까지 기다리고 branch 생성하는건 시간이 없을 수 있다.

 

예를들어 과제하는 상황에서 자주 일어나는데, 1주차 과제를 하고 PR 올렸는데 과제 검사를 받느라 merge 안 된 상태로 2주차 과제(1주차 과제의 코드가 필요한 작업) branch를 파서 진행하고 또 PR 올리는 경우, 1주차의 commit 내역들이 따라오곤 한다.

 

 

 - 다른 branch의 commit내역들이 따라오는게 뭐가 문제냐?

일단 무엇보다도 코드 리뷰어들이 코드 리뷰하기 힘들다. 수정된 코드 양이 상당하다면 다 검사할 생각에 벌써부터 힘이 들곤 한다...

같은 PRd에 대해 (왼) 이전 커밋이 따라온 경우    (오) 이전 커밋이 따라오지 않은 경우(하단의 해결법으로 문제 해결한 경우)

 

같은 작업 내역에 대해 왼쪽 보다는 오른쪽 처럼 작업한 코드내역만 볼 수 있는 경우가 피로도가 적을 것이다.

PR의 목적이 명확하며 해당 이슈에 관련된 커밋만 확인할 수 있고 더 정확한 피드백을 줄 수 있다.

 

왼애초에 develop에서 새 작업 브랜치를 팔 수 있도록 작업이 분리되는게 좋지만 이미 실패한 경우라면 어쩔 수가 없다^_^

그럴때 내가 의도했던 이번 브랜치에서만의 작업 내역만을 리뷰어들에게 보여주기 위해 쓰는 방법이 있다.

 

---

  - 해결 방법  (base 변경) 

(기존)

보통 develop branch로 PR을 보내 base가 develop일 것이다.

 

(수정)

PR 제목 옆 Edit 버튼을 눌러 base가 develop이였던 것을 commit들이 따라오던 branch로 변경해준다

 

 

---

  - 해결 완료  

내가 의도하던대로 branch #52를 만들고 난 후에 commit했던 내역들만 확인할 수 있다. 

 

---

  - 추가 지식 

Pull Requests vs Stacked Changes [2022 인프콘]

인프콘 2022

 

 

Graphite 툴 사용