이미 PR을 생성한 브랜치로부터 또 새로운 브랜치를 생성한 경우

C로부터 checkout 하여 D-E-F를 포함하는 feat1 브랜치로 PR을 생성한 후에, 이어진 작업으로 인해 feat1 브랜치로부터 feat2 브랜치를 생성하고 작업을 진행하면 feat1 브랜치가 머지된 이후에도 feat2 브랜치의 PR에 의도치 않은 커밋이 남아있게된다.

 

 

예시.

A - B - C            --- develop 브랜치
         \
          D - E - F  --- feat1 브랜치

이어진 작업으로 인해 feat1 브랜치로부터 feat2 브랜치를 생성하고 작업을 진행

A - B - C            --- develop 브랜치
         \
          D - E - F  --- feat1 브랜치
                   \
                    G - H - I --- feat2 브랜치

feat1 브랜치를 develop 브랜치로 머지하면, feat2 브랜치에 의도치 않게 feat1 브랜치의 커밋이 달리게 된다.

A - B - C - D - E - F  --- develop 브랜치
                     \
                      D - E - F - G - H - I --- feat2 브랜치

feat2 브랜치를 머지하게 되면 D - E - F 는 동일한 해시를 갖기 때문에 중복으로 커밋이 생기지는 않지만

기능을 분리하여 PR을 생성한다는 관점에 맞지 않고, 코드 리뷰시에도 feat1 브랜치의 작업 내역이 모두 포함되다 보니 상당히 불편하다.

게다가 feat1 PR의 코드 리뷰에서 수정 요청이라도 생겼다 하면 이렇게 된다.

A - B - C            --- develop 브랜치
         \
          D - E - F - F' --- feat1 브랜치
                   \
                    G - H - I --- feat2 브랜치

코드 리뷰를 마치고 feat1 을 머지하면.

A - B - C - D - E - F - F'  --- develop 브랜치
                         \
                          D - E - F - G - H - I --- feat2 브랜치

feat1 에서 수정 사항이 생겼을 때 feat2 에는 그 내용이 반영되지 않았기 때문에 까닥하면 F’을 덮어쓰는 상황이 생길수도 있다.(확인 필요)

 

 

 

따라서, 이런 경우에는 rebase를 통해 feat2 에서 진행한 내용이 아닌 커밋은 제거해주는 것이 좋다.

git rebase -i HEAD~6 # DEFGHI: 6개

pick D
pick E
pick F
pick G
pick H
pick I

이런식으로 에디터가 표시되면 feat2 에서 진행하지 않은 D, E, F를 drop 하자.

d D
d E
d F
pick G
pick H
pick I

만약 drop 작업으로 인해 feat2 에서 병합이 필요한 작업이 생기면 git이 알려준다. 그런 경우에는 머지 충돌을 해결할 때와 유사하게 진행하면 된다.

A - B - C - D - E - F - F'  --- develop 브랜치
                         \
                          G - H - I --- feat2 브랜치

이렇게 그래프에 중복되는 것을 제거하고 나면 PR 에서도 작업한 내용만 노출된다.

 

이상적인 것은 아직 병합되지 않은 브랜치로부터 또 브랜치를 생성하지 않는 것인데, 실무는 워낙 일정이 긴박하고 연결된 기능들을 구현하는 중에 미리 생성한 PR에 대한 코드 리뷰를 기다리고만 있을 수 없다보니 병합되지 않은 브랜치로부터 브랜치를 생성하는 경우가 종종 발생하는 것 같다.

 

브랜치 생성을 이미 그렇게 해버렸다면 이전 브랜치가 병합된 후에, 다음 브랜치에서는 병합된 커밋을 지워서 PR이 의도한 내용만을 포함할 수 있도록 관리하는 편이 좋을 것 같다.
(PR이 이전 브랜치의 작업 내용을 모두 포함하고 있어 코드 리뷰 시에 불편함이 있으니, 이전 브랜치가 병합되기 전까지는 다음 브랜치의 PR을 draft 상태로 해놓는것도 상당한 센스이지 않을까?)

 

물론 브랜치가 두 세 개 정도라면 이렇게 일일이 삭제하는 것도 할만한데, 너무 주렁주렁 달리게 될 거라면 차라리 방식을 변경하는 것이 좋다.

큰 기능이 아닌 경우라면, 차라리 develop 브랜치로부터 새로운 브랜치를 생성한 후에 feat2 브랜치에서 실제로 작업한 커밋을 cherry-pick으로 가져오자.

큰 기능을 다루고 있다면, 처음부터 해당 기능을 위한 feature 브랜치를 생성하고 기능을 잘게 나눈 기능 조각들은 feature 브랜치로부터 브랜치를 생성하여 진행하고, 기능 전체의 구현이 완료되면 feature 브랜치를 한 번에 병합하자.

기능 조각에 대한 브랜치에서 코드 리뷰를 마쳤으므로 마지막 병합시에도 코드 리뷰에 큰 부담이 없다.