[Git] Pull Request 반으로 쪼개기🔪

커밋별로 PR을 분류하는 방법과 깃 명령어에 대한 설명을 다룹니다.

(PR == Pull Request)

개요

아마 나처럼 아직 깃허브 사용에 익숙하지 않은 사람이라면 위와 같은 실수를 해본 경험이 있을 것이다. 위 사진은 DevCamp 활동이 끝나고 아직 끝내지 못한 작업들을 보충하기 위해 올린 PR인데(이전 포스팅 참고), 브랜치 나누는 것을 잊고 여러 작업을 한 브랜치에서 작업하는 바람에 한 PR에 몽땅 올라가버린 모습을 볼 수 있다.

저렇게 한 PR에 여러 변경점들이 들어가면 리뷰하기도 어렵고 나중에 코드를 추적하는 것도 까다로워진다. 그래서 내가 올린 저 PR은 받아들여지지 않았고, 대신 하나의 PR에는 하나의 의미적 변겅사항만 담기도록 나누어 올려달라는 요청을 받았다.

이번 포스팅에서는 얼떨결에 받은 ‘하나의 PR(pull request)을 여러 개의 PR로 분류하기’라는 과제를 수행했던 과정을 공유하려 한다.

📒 TL;DR (Too Long; Didn’t Read)

한 브랜치의 작업을 분리하고 PR 생성하는 방법 요약

1. 작업 브랜치(develop 브랜치)에서 적절한 과거 시점을 선택해 새 feature브랜치를 분기한다.
2. 만들어진 feature 브랜치로 이동하고, develop 브랜치에서 원하는 변경사항들을 cherry-pick 명령어로 가져온다.
3. 만약 여러 개의 feature 브랜치로 나누고 싶다면 1, 2번을 반복한다.
4. 각 feature 브랜치에서 각각의 PR을 생성한다.

아마 깃 사용에 익숙하신 분들은 당연하다고 생각할 수도 있지만, 내가 처음에 저 요청을 받았을 때는 나 같은 사람들을 위해 커밋들을 쏙쏙 뽑아서 PR을 올리는 기능이 있는 줄 알았다. 하지만 검색해도 그런 기능이 보이진 않았다. (당시에는 한글로만 검색했는데 나중에 ‘split pull request’처럼 영어로 검색하니까 기능은 아니지만 해법이 바로 나오더라.. 우리 모두 검색할 땐 영어를 사용하자)

우선 Pull Request이 무엇이고 어떻게 동작하는지 지금까지 PR을 올린 경험을 기반으로 생각해보자. 내가 경험적으로 알고 있는 PR은 한 브랜치에서의 변경사항을 다른 브랜치에 병합(merge)하기 전, 해당 저장소 주인에게 허락을 요청하는 것이다. 여기서 비교의 기준은 브랜치이고, 내가 한 브랜치에 모든 작업을 올렸던 것이 문제였다. 그렇다면 커밋들을 각 브랜치로 옮기면 되겠구나!

다행히 하나의 커밋에 여러 변경사항이 들어간 경우는 없어서 커밋을 둘로 쪼개는 짓은 하지 않아도 됐다. 일단 여기까지 생각이 미치고 나니 또다른 걸림돌에 막혔다.

이미 올린 커밋을 어떻게 다른 브랜치로 옮기지?

이건 깃 명령어를 잘 활용하면 해결될 문제라고 판단해서 깃 명령어들의 개념과 원리들을 찾아봤다. 이렇게 개괄적인 개념을 처음 학습할 때는 생활코딩 강의 영상만한 게 없는 것 같다. 나는 위 동영상을 여러 번 시청하면서 3-way-merge를 기반으로 한 merge, cherry-pick, revert, rebase의 개념을 파악할 수 있었다. 이 네 개념에 대해 추가적으로 더 공부해서 아래에 설명을 쓸 계획이다.

답은 cherry-pick에 있었다

이 중 내가 필요로하는 ‘커밋을 옮기는’ 기능은 cherry-pick 에 있었다. 정확히는 커밋을 옮기는 것은 아니고, 해당 커밋의 변경사항만 가져와 다른 브랜치에 적용하는 것이라고 간단히 설명할 수 있을 것 같다.

1. 브랜치 분기하기

여러 PR을 생성하는 것이 목적이니까 그것에 대응되는 브랜치도 여러 개 만들어야 한다. 어느 시점을 기준으로 브랜치를 분기하냐가 중요할텐데, 그냥 적당히 작업을 시작한 시점을 기준으로 잡으면 될 것 같다.

특정 시점(커밋)에서 브랜치를 만드는 방법은 다음과 같다. (참고: https://www.techiedelight.com/create-branch-from-previous-commit-git/)

1. CLI에서 하는 방법

$ git checkout <commit-id>
$ git checkout -b <branchname>

1. 깃허브 사이트에서 하는 방법

레포지토리의 특정 커밋을 찾고, 사진에 보이는 버튼을 누른다.

버튼을 누르면 해당 시점의 레포지토리로 이동하게 되는데, 그 상태에서 브랜치를 새로 만들면 된다.

2. cherry-pick 명령어로 변경사항 하나씩 가져오기

이 단계는 CLI 명령어로만 가능하다.

만약 이 브랜치에서 ‘fix: YdsNightBasicColors의 Gray 색 수정’ 커밋의 변경사항을 가져오고 싶다면 커밋의 해시값이 ‘11b79’로 시작한다는 것을 기억하고, 아래 명령을 입력한다. (feature/compose_night_gray는 앞 단계에서 분기한 브랜치라고 가정한다.)

$ git checkout feature/compose_night_gray
$ git cherry-pick 11b79

이렇게 하면 compose 브랜치에 있던 ‘fix: YdsNightBasicColors의 Gray 색 수정’ 커밋이 feature/compose_night_gray 브랜치에도 생기면서 해당 커밋에서 수정했던 사항들이 반영되는 것을 확인할 수 있다. 로컬 디스크에만 적용된 상태이기 때문에 git push 하여 깃허브 레포지토리에 올리는 것을 잊지 말자.

3. Pull Request 생성하기

1번과 2번 단계를 반복해서 원하는 상황까지 만들었다면 이제 각 브랜치마다 Pull Request를 만들자. PR을 생성하는 방법은 이 포스팅 주제를 넘어가므로 다루지 않으려 한다.

끝!

오픈소스에 기여하는 활동을 하다보니 깃과 관련된 지식을 점점 더 공부하게 되는 것 같다. 그전까지는 깃과 깃허브를 다룰 때 커밋, 푸시와 브랜치 만들고 PR을 보내는 것만 할줄 알아도 된다고 생각했었다. 하지만 이번 과제를 수행하면서 깃만 해도 배울 것이 무궁무진하다는 것과 그렇게 배운 것이 나중에 다 쓸 데가 있을 것이라고 생각이 들었다. 한 번 공부하는 거 제대로 알고 넘어가기 위해 열심히 공부해야겠다.