[Github] Pull request

지금까지의 글을 통해 우리는 브랜치를 만들고, 만든 브랜치를 master로 병합할 수도 있게 되었습니다. 그런데 충돌을 해결했다고 무작정 master로 병합하는 것이 적절할까요? 예를 들어 신입 A가 master에 코드를 병합하기 전에 선임 B의 검토를 거쳐야 하는 상황이 있을 수 있습니다. 이런 경우에는 A가 (설령 권한이 있다고 해도) 직접 master로 병합하는 대신, 코드를 검토해 달라는 요청을 B에게 보낼 필요가 있습니다.

 

Git의 pull request 기능을 이용하여 보다 더 수월하게 협업해 봅시다.

 

Pull request 만들기

우선 pull request를 보낼 커밋을 만들어야 합니다. 제 브랜치 branch-mwy에서 테스트 커밋을 하나 올리고 push해 보겠습니다. 아직 이 커밋은 master와는 관계없는 커밋입니다.

 

Branch - Create pull request를 클릭합니다.

 

클릭하면 Github repository로 이동합니다. 먼저 base와 compare를 확인시다. compare는 커밋한 코드가 있는 브랜치로, base는 병합한 결과를 저장할 브랜치로 지정해야 합니다. 아마 자동으로 잘 설정되어 있을 겁니다.

원격 저장소에 커밋이 push되었는지 확인하고, pull request의 제목과 내용을 적어서 초록색 Create pull request 버튼을 누르면 됩니다.

 

# 오른쪽 메뉴의 의미

Reviewers

Pull request를 검토할 사람을 지정할 수 있습니다. 상황에 맞게 같은 팀원 또는 해당 기능을 함께 개발하는 사람을 선택하면 됩니다.

 

Assigners

Pull request를 담당하는 사람을 지정합니다. 보통은 자기 자신을 지정합니다.

 

Labels

Pull request에 라벨을 달 수 있습니다. 버그, 검토 필요 등등이 있습니다.

 

Milestone

어떤 목표를 달성했다..는 뜻의 마일스톤(이정표)입니다. 딱히 쓸 일은 없을 것 같습니다.

 

Pull request가 만들어졌습니다. 이제 우리 조원들이 코드를 검토하고, comment로 토론하고, reviewers 중 한 명이 pull request를 수락(accept)할 수도 있습니다. 커밋에 문제가 있는 경우 수정을 요청(request change)할 수 있으며, 그렇지 않은 경우 병합할 수도 있습니다.

 

Github desktop에서도 확인할 수 있습니다. VSCode 등의 IDE에서는 플러그인을 통해 pull request를 볼 수 있습니다. 

코드 라인마다 댓글을 달 수도 있다.

 

지금은 커밋에 문제가 없다고 가정하고, 커밋을 master로 병합하도록 하겠습니다. Conversation 탭에 영롱한 초록색 버튼이 보입니다. 버튼을 클릭합시다.

 

병합 커밋을 만드는 창이 보입니다. 브랜치를 병합하듯이 제목과 내용을 써 주면 됩니다. 

 

 

Pull request가 성공적으로 병합되었습니다. 이제 우리는 커밋을 정중하게 병합할 수 있습니다.

Merged

병합된 pull request는 closed 상태로 바뀌며, Pull request 탭의 Closed에서 확인할 수 있습니다.

 

Github desktop으로 확인해 보니, master 브랜치에 pull request 병합이 정상적으로 반영되었습니다. 잘 하셨습니다!

 

IntelliJ에서도 확인할 수 있습니다.