Pull Request 코드 리뷰하기

저번 포스팅에서 깃허브의 merge 방식까지 공부를 진행해보았습니다. 하지만, 코드 리뷰 없이 바로 merge 하는 경우는 매우 드뭅니다. 팀원이 보낸 PR에 대해 누군가는 코드를 리뷰한 후, merge를 승인하거나, 거부해야합니다. 그러려면 코드를 리뷰하는 방법을 알고 있어야 할 것입니다. 그래서 이번 포스팅에서 그 내용을 다뤄보도록 하겠습니다.

1. PR 코드를 로컬환경에 저장하기

① Organization에서 fork된 파일을 git clone하여 IntelliJ에서 열어준다. 방법이 기억나지 않는다면, 아래의 링크를 참조하라.
>> 저번 포스팅

② 클론한 파일을 우클릭 > Git Bash Here을 클릭하여 Git 실행창을 연다.

③ 아래의 명령을 순차적으로 입력한다.

$ git clone {저장소 HTTPS주소}
$ cd {Repository 이름}
$ git config --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"
$ git fetch origin
$ git checkout -t origin/pr/{가져오고자 하는 PR 넘버}

• git clone https://github.com/UMC-Hello-There/HelloThere.git // HTTPS 주소 복사 붙여넣기
• cd HelloThere // Repository 이름
• git config --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"
• git fetch origin
• git checkout -t origin/pr/2 // 2번 pr을 가져온다.

④ 클론한 파일의 로컬 저장위치에 가보면, HelloThere이라는 디렉토리가 생겨있는데, 이 안에 2번 pr 코드가 담겨 있다.

⑤ 편의상 이름을 pr#2로 바꾸자.

⑥ 이제 이 파일을 인텔리제이에서 열어주면 된다.

2. Conflict 해결하기

1) PR이 해결되기 전에 팀원이 commit을 다시 보낸 경우

방금 생성한 pr#2 파일을 우클릭하여 Git 실행창을 띄우고 아래의 명령을 순차적으로 입력한다.

$ git fetch origin pull/{pr 번호}/head:{브랜치 이름}
$ git merge {브랜치 이름}

① git fetch origin pull/2/head:HelloThere-2

• 여기서 브랜치 이름은 이슈 넘버가 아니라, pr 넘버에 맞추어져 있다.
• head는 변경사항을 저장할 로컬 브랜치의 이름을 설정하는데, 여기에 작업하고 있는 브랜치의 이름을 넣으면 된다.

② git merge HelloThere-2

• 가져온 변경사항을 작업 중인 브랜치에 병합한다.

③ 충돌여부 확인

• 충돌이 발생하지 않는다면, 변경 사항을 가져올 수 있다.
• 충돌이 발생하면, 어디서 충돌이 발생했는지 확인하고 이를 해결해주어야 한다.

2) 두 개의 pr을 받았고, 1개의 pr이 merge된 경우

2번째 pr에는 새로운 변경 사항이 적용되어 있지 않을 것이다. 일단 2번 pr도 위에서 설명한 방법으로 로컬로 가져오고 git 실행창을 열어주자. 그리고 아래의 명령을 입력한다.

$ git remote add upstream {Organization Repository의 HTTPS 주소}
$ git fetch upstream
$ git merge upstream/main

conflict가 발생할 경우 적절하게 수정해주면 된다. 만약 이미 로컬에서 수정이 진행 중이었을 때 위 명령을 사용하면 덮어 씌우기로 인해 수정한 사항이 날아갈 수 있다는 경고와 함께 수정 사항을 받아오지 않는다. 그럴 때는 아래의 명령을 사용하면 된다.

$ git add {수정한_파일} // 또는 git add .
$ git commit -m "Committing local changes before merge"
// 물론 커밋메시지는 원하는대로 변경 가능하다.
$ git merge upstream/main

아래와 같이 나오면서 변경사항이 내 로컬로 가져와진다.

confilct가 많아 자동 merge에는 실패했으나 로컬의 인텔리제이 파일에 변경 사항은 가져와진다. 이제 직접 conflict를 해결하면 된다. 참고로 conflict가 생긴 파일은 이름이 빨간색으로 변하기 때문에 conflict가 발생한 파일을 쉽게 식별 가능하다.

3) conflict를 다 해결했는데 confilct 때문에 commit할 수 없다고 하는 경우

다시 git 실행창을 열어 아래의 명령을 입력하면 된다.

$ git commit -am 'commit_message'

만약 최근 커밋에 대해 메시지를 수정하고 싶다면 아래의 명령을 사용하면 된다. 만약 Github 브랜치 전략을 사용하고 있다면, 커밋 메시지는 본인의 브랜치 이름이 되어야할 것이다.

$ git commit --amend -m "commit_message"

4) 깃허브에서 충돌을 해결하기

깃허브에서 곧바로 conflict를 해결할 수 있는 솔루션도 존재한다. 팀원이 보낸 pr의 코드와 Organization Repository의 코드에 충돌이 발생하는 경우 PR을 곧바로 merge할 수 없다는 경고창이 나오면서 아래와 같이 Resolve conflicts 버튼이 생긴다. 이 버튼을 클릭해주자.

그러면 아래와 같이 어디서 충돌이 발생했는지 보여준다. =======을 기준으로 위쪽은 HelloThere-7 브랜치의 코드(팀원의 pr코드)이고, 아래쪽은 main 브랜치의 코드(Organization Repository의 코드)이다.

충돌을 해결하면 빨간 줄이 지워진다.

conflict에 대한 처리가 완료되면 우상단에 Mark as resolved 버튼이 클릭 가능해진다. 이것을 conflict가 발생하는 모든 파일에 대해 클릭하면 아래와 같이 될 것이다. 이렇게 모든 파일에 대해 conflict가 해결되면 merge할 수 있게 된다.

※ 깃허브에서 conflict를 해결하고 로컬로 pr을 받아온다고 해서 conflict가 해결된 채로 로컬로 받아와지는게 아니라 처음 pr 그대로 로컬로 받아와진다. 따라서 이 방법은 충돌이 많지 않아 곧바로 깃허브에서 conflict를 해결하는 편이 낫겠다고 판단될 때에만 사용하도록 한다. 로컬로 가져와서 코드리뷰를 해야하거나 충돌을 해결해야하는 경우에는 적합하지 않은 방법이다. 실제로 conflict가 복잡한 상황에서는 Resolve conflicts 버튼이 비활성화된다.