PR(pull request)가 뭐야?

pull request 란?

팀 단위에서 작업을 할 때 코드 리뷰 등의 이유 때문에 git 을 활용해 형상관리를 진행한다. 이때, 코드 리뷰를 쉽게 하기 위해 PR(Pull Request)를 사용하면 어떤 작업이 적용되었고 어떤 코드가 추가되었는지 쉽게 파악할 수 있다.

코드를 파악할 때에 추가로 더 확인하면 좋은 것이 커밋명이다. 코드를 리뷰하는 사람이 이 코드들이 어떤 동작을 하는지 하나하나 읽고 파악하기 전에 커밋명을 읽고 아 이런 작업을 했구나라는 생각을 갖고 코드를 읽게 된다면 리뷰를 하는 사람도 작업의 의도와 코드의 동작을 비교하며 리뷰할 수 있고 작업자 역시 리뷰를 받고 코드를 수정할 일이 있을 때 해당 커밋만 다시 불러와 작업할 수 있는 이점을 갖고 있다.

PR을 하는 방법

origin 과 upstream 을 구분하고 브랜치를 따로 따서 작업하는 것이 중요하다.

1. 먼저, 팀 프로젝트를 본인의 깃으로 fork 해서 로컬 작업소로 clone 해온다.

git clone <깃허브 경로>

2. clone 했다면 다른 작업 전에 remote 경로를 정하는 것이 중요하다.

origin remote 에는 본인의 깃 경로를, upstream remote 에는 팀의 깃 경로를 지정해둔다면 혹시나 모를 push 실수를 방지할 수 있다.

git remote add origin <본인 깃허브 경로>
git remote add upstream <팀 깃허브 경로>

remote 경로 작업을 마쳤다면 맡은 부분에 대해 로컬에서 작업을 하면 되는데 이때 주의해야할 점은 꼭 branch 를 따서 작업을 해야한다는 점이다. 이 이유는 다른 사람의 작업 내용을 내려받을 때 충돌이 나지 않도록 하는 이유도 있으며 깃 히스토리 그래프를 잘 유지할 수 있는 장점도 있다.

git checkout -b <branch 명>

이 명령어를 사용한다면 존재하지 않는 브랜치라면 생성하고 바로 브랜치 이동까지 할 수 있다.

3. 옮긴 브랜치에서 작업하기

이제 맡은 기능들을 모두 구현하면 된다.

4. 커밋 만들기

작업한 내용에 대해서 기능 단위로 잘게잘게 쪼개어 커밋을 작성한다.

커밋을 잘게잘게 쪼개어 작업하는 이유는 다양하게 있겠지만 무엇보다 어떤 기능을 만들었는지 명확하게 확인할 수 있는 것이 가장 큰 장점이다.

5. 작업한 내용을 push 하기

작업 내용을 먼저 origin remote 경로에 업로드 한다.

git push -u origin <브랜치 명>

u 옵션은 현재 브랜치에서 다음 작업을 하고 다시 push 를 진행할 때 다음에는 origin 의 브랜치를 명시하지 않아도 알아서 지정한 remote 브랜치로 올라가게 해주는 옵션이다.

push 를 하게 되면 터미널 상에 pull request 를 위한 url 이 나오기도 하고 직접 팀 프로젝트 깃 경로에 들어가도 pull request 를 보내라는 버튼이 활성화 되어있다.

그 버튼을 눌러 url 을 따라가면 upstream 의 어떤 브랜치에 병합할 것인지부터 어떤 작업을 했는지 작성할 수 있는 폼이 있다.

6. 리뷰받고 코드 병합하기

리뷰받은 부분을 수정하고 크게 문제가 없다면 코드를 병합을 진행한다. upstream 저장소의 병합이 완료되면 origin 과 local 저장소 모두 git pull 을 진행한다. 이때 깃 히스토리 그래프를 이쁘게 유지하기 위한 방법으로 pull 을 받을 때 --rebase 옵션을 사용한다.

git pull --rebase upstream master

pull 을 받을 때 로컬의 HEAD 와 upstream 의 HEAD 를 정리하는 것인데 깃 히스토리를 강제로 변경하여 깔끔한 그래프로 만들 수 있다.

로컬 저장소의 pull이 완료되었다면

git push -u origin master

를 통해서 origin 저장소 역시 최신화를 만들어 줄 수 있다.

번외. local branch 의 rebase

만약 local 저장소의 master 브랜치가 현재 upstream 저장소의 HEAD 와 같은 커밋을 가르키고 있는 상태에서 새로 브랜치를 만들어 추가적인 커밋을 진행한다면 새로운 브랜치가 master 브랜치보다 앞서게 된다. 이런 상태에서 PR을 보내게 되면 자칫 코드가 꼬이거나 깃 히스토리 그래프가 꼬일 수 있기 때문에 리베이스를 통해 베이스 커밋을 새로 만들어주어야 한다.

git rebase master