pull request

1. Pull Request

코드를 다 수정했으니 이제 원본 리포지토리에 Pull Request를 보내봅시다.

이때 왜 Pull Request를 사용해야 하는지 궁금한 분들도 있을 겁니다.

혼자 진행하는 프로젝트라면 전혀 문제가 없지만, 여러 명이 한 프로젝트를 진행할 때 Pull Request가 필요하게 됩니다. Pull Request를 사용한다면 아래의 장점이 존재합니다.

코드 충돌 최소화

모두가 원본 리포지토리에서 작업을 하게 된다면 코드 충돌이 하루에도 수십 번 일어날 수 밖에 없습니다.

특히 한 명이 Push를 하는 순간, 똑같은 파일을 수정한 다른 모든 사람들이 Push를 하려고 하면 충돌을 피하기 위해 원본 리포지토리를 최신 버전으로 업데이트 해야 합니다. 그리고 이걸 Push를 하려고 할 때마다 반복해야 합니다.

코드 리뷰

여러 명이 협업하여 진행하는 작업의 경우에는 나중에 자신의 코드를 다른 사람이 수정할 수도 있다는 것을 고려해야 합니다. 그 반대의 경우도 마찬가지입니다. 그리고 이왕이면 기능을 추가할 때 최대한 성능을 끌어올리는 것도 중요하기 때문에, 원본 리포지토리를 합치기 전에 수정할 부분이 있으면 더 수정을 하고 합치는 것이 좋습니다. 그래서 다른 사람들이 내 코드를 확인하고, 의견을 나눌 수 있는 기능도 제공합니다.

이전 기록을 확인하기 용이함

보통 커밋 메시지를 보낸다면 하나의 기능을 만들 때, 수십 개의 커밋 메시지를 보내는 경우가 많습니다.

회사에 들어가게 된다면 처음부터 시작하는 프로젝트가 아닌 이미 진행중인 프로젝트에 투입이 되는 경우가 대부분이고, 이런 경우엔 수백개 ~ 수만개의 커밋 메시지가 있기 때문에 내용이 서로 비슷한 커밋 메시지가 존재하기 마련입니다.

이때는 커밋 메시지만 본다면 무슨 기능을 위해 커밋 메시지를 작성했는지 파악할 수가 없습니다. 하지만 Pull Request를 통해 어떤 기능을 위해 작성된 커밋 메시지들을 확인할 수 있으면 어떤 의도로 코드를 작성했는지 명확히 파악할 수 있으므로 이전 기록을 확인하는데 좋습니다.

2. 실습

이제 왜 Pull Request를 사용하는지 알게 됐으니 Pull Request를 보내봅시다.

Pull Request를 보내는 방법 자체는 간단합니다.

먼저 자신이 커밋 메시지를 보낸 리포지토리가 맞는지 확인합니다.

왼쪽 위에 빨간 박스처럼 자신의 아이디가 적혀있고, 가운데에 1 이상의 숫자가 x commit ahead로 되어 있다면 잘 따라온 것입니다. 현재 저는 1개의 커밋만 보냈기 때문에 1이라고 표시되어 있는 것이지 여러 개의 커밋 메시지가 있어도 상관이 없습니다.

여기서 Contribute 버튼을 누르고 Open pull request 버튼을 클릭합니다.

이제 Pull Request를 보낼 수 있는 내용들이 나옵니다.

가운데 - 제목과 내용

제목엔 어떤 코드 기여를 하는 것인지 요약하는 내용을 적어주고, 세부 내용에 자세한 내용을 작성합니다.

오른쪽 - 다양한 옵션

• Reviewers는 리뷰를 요청하는 유저를 선택하는 기능입니다. 이때 리뷰 요청을 하면 리뷰어에게 메일이 날아오게 됩니다.

• Assignees는 해당 코드를 작성한 유저가 누구인지 선택하는 기능입니다.

• Labels는 해당 Pull Request가 어떤 유형에 속하는지 선택하는 기능입니다. (ex. 새로운 기능, 간단한 개선, 문서 작성, …)

• Projects는 Repository 옵션중에 하나인 Projects에 작성되어 있는 내용과 연결할 때 사용합니다. 대표적인 예시로는 스프린트로 계획을 세웠을 때, 해당 PR이 몇 번째 스프린트에서 적용하는 PR인지 기록할 때 사용합니다.

• Milestone은 어떤 목표를 위해 적용하는 PR인지 정해주는 기능입니다. 만약 ‘버튼 추가’라는 기능을 만드려고 할 때, 여러 개의 PR을 보내게 된다면 Milstone에 버튼 추가라는 내용을 만들어 적용할 수 있습니다.

아래 - 커밋 메시지와 파일 변경 내용

어떤 커밋 메시지를 보냈는지, 해당 PR에서 어떤 파일의 어떤 코드가 수정/추가/삭제 됐는지, 누가 기여를 하는지 보여줍니다.

이제 모든 게 결정 됐다면 이제 Create pull request 버튼을 누릅니다.

3. Pull Request를 생성한 이후

Pull Request를 생성하게 된다면 결론적으로 네 가지 상태로 나뉘게 됩니다.

• Open : 아직 원본 리포지토리에 반영하기 전이고, 기능이 완성된 상태이니 코드 리뷰를 받을 상태가 된 것입니다.

• Draft : 아직 원본 리포지토리에 반영하기 전이고, PR을 생성했지만 기능이 완성된 상태가 아니니 확인하지 말라는 의미입니다.

• Merged : 원본 리포지토리에 코드를 반영합니다.

• Closed : 원본 리포지토리에 코드를 반영하지 않은 채로 종료합니다. 다시 Open으로 바꿀 수 있습니다.

Merged와 Closed는 크게 설명할 내용이 없지만, Open 상태에서는 큰 특징이 있습니다.

바로 Open이 된 상태에서 다른 파일을 수정해 커밋 메시지를 Push할 경우, 해당 PR에 커밋 메시지가 남게 된다는 점입니다. 이 말은 PR은 항상 최신 버전으로 유지가 된다는 것입니다.

그래서 동시에 여러가지의 작업을 진행해야 할 때에는 브랜치라는 기능을 사용하게 됩니다. 코딩을 좀 오래하신 분이라면 인터넷에서 브랜치 전략이라는 단어를 들어 봤을 겁니다.