pull request는 다른 서비스에서는 merge request라고도 불리는데, 독립적으로 진행되던 브랜치의 작업을 다른 브랜치에 병합해달라고 요청하는 기능이다.
대표적인 경우는 이렇다. master 브랜치의 마지막 버전은 언제나 실행/배포 가능한 상태를 유지하기로 협의한 팀이 있다고 하자. 모든 작업은 별도의 브랜치를 만들어서 그곳에서 작업을 진행하기로 했다. 이런 브랜치를 토픽 브랜치, 기능(feature) 브랜치라고 한다. 모든 작업이 끝나고 토픽 브랜치를 master로 병합할 때 다른 사람들의 검토를 받도록 하고 싶다면 어떻게 해야 할까? 이때 사용할 수 있는 최고의 기능이 pull request이다. pull request를 이용하면 브랜치에서 만들어진 버전의 내용을 검토함으로써 코드의 품질을 높일 수 있다. 충분한 검토가 끝났을 때 github.com에서 병합 버튼을 누르면 자동으로 브랜치가 병합된다.
내가 exp 브랜치에서 작업을 끝낸 뒤 원격 저장소에 pull request를 보내면,
원격 저장소의 다른 멤버들은 내가 보낸 버전에 대해 토론하기 시작한다. 이 부분은 고치자, 이 부분은 그대로 놔두자 의논하면서 코드의 품질을 높이기 위한 작업을 하는 것이다.
충분한 검토를 거친 뒤 github.com에서 병합 버튼을 누르면, 새로운 버전이 만들어지면서 exp 브랜치가 master 브랜치에 병합되게 된다.
이 병합된 master 브랜치는 다른 멤버들의 지역 저장소에도 그대로 반영된다.
pull request의 핵심적인 기능은 내가 작업한 코드를 다른 멤버들이 검토해서 코드의 품질을 높이고, master라는 통합 브랜치의 안정성을 높이는 것이다.
아래 사진은 새로 만든 레포지토리에 버전을 생성하고 3개의 커밋에 대한 푸시까지 완료한 상태이다. 그러면 원격 저장소에서 pull request 버튼을 누를 수 있게 된다.
이 예제는 테스트용이기 때문에 내가 merge 권한까지 갖고 있어서 number-to-alphabet 브랜치에서 작업한 내용을 main 브랜치에 직접 병합할 수 있다. 하지만 실제로는 내가 보낸 PR에 대해 다른 멤버분들이 코드리뷰를 진행하고, 최종적인 검토가 끝난 뒤에 병합을 할 것이다.
병합이 완료된 후 pull을 통해 원격 저장소와 동기화 시키면, 다음과 같은 커밋 로그를 확인할 수 있다.
아래 사진은 pr을 완료한 뒤에 지역 저장소의 현재 브랜치를 main으로 전환하고, 더 이상 필요하지 않은 number-to-alphabet 브랜치는 삭제한 것이다.
병합 전에 충돌이 발생하면 깃헙 에디터에서 수정하거나, cli 명령으로 해결할 수 있다.
