팀 프로젝트를 위한 매뉴얼(3) - 협업 필수 기능 Pull Requests

Intro

앞선 글들에서는 프로젝트 시작 전, 정해야할 규칙, 프로젝트 세팅하는 방법에 대해 설명했다.

팀 프로젝트를 위한 매뉴얼(1) - 규칙 정하기

팀 프로젝트를 위한 매뉴얼(2) - 프로젝트 세팅하기

 

세팅을 완료했으니 이제 개발을 시작하면 된다!

 

하지만 개발 과정에서 다양한 문제 상황이 발생할 수 있고, 그것으로 인해 몇시간, 심하면 며칠동안 삽질할 수 있다.

이번 글에서는 해당 문제 상황을 예방하기 위해, 혹은 효율적인 협업을 하기 위해 거의 필수적으로 사용해야하는 Pull Requests에 대해서 다뤄보고자 한다.

 

PR(Pull Requests)이란? 

Pull Requests는 말 그대로  '끌어오기 요청'이다.

내가 짠 코드를 해당 브랜치에 끌어오게(pull) 해주세요!

 

왜 PR을 사용해야하는가?

개발을 진행할 때 보통 각자의 branch에서 코드를 짠다고 '규칙 정하기' 글에서 설명하였다.

각자의 브랜치에서 개발을 하고 추후 develop 브랜치에 합칠 때, 혹은 다른 팀원 기능 개발하는 것을 도와주고 해당 코드를 합칠 때 등, 코드를 병합하고자 할 때 그냥 push하고 pull하면 코드가 꼬이는 일이 일어날 수 있다.

 

아래 예시 코드를 보자. 아마 merge나 pull 명령어로 코드를 병합했는데, 원격(github)에 있는 코드와 로컬(내 PC)에 있는 코드와 어긋났을 때 발생한 것이다.

code conflict (출처: vscode 공식문서)

<<<<< HEAD 위에 선택지들이 있다. 이를 통해 본인이 원하는 코드로 설정하면 된다.

• Accept Current Change: 로컬에 있는 코드로 설정
• Accept Incomming Change: 원격 코드를 코드로 설정
• Accept Both Change: 두 코드 다 가져온다. 
• Compare Changes: 비교를 더 직관적으로 해보는 창으로 넘어간다. 

 

그런데 위와 같이 컨플릭트가 나면 무슨 코드를 수정해야 하는 지는 해당 부분을 개발한 팀원이 분석하고 수정 해야 할 점을 알려줘야지 수정할 수 있다. 그리고 만약 팀원들 모두 충돌난 코드를 가져온 상황이면  모두가 다 수정해야하고 불필요한 commit들도 많이 쌓일 것이다.

그리고 그 수정하는 과정에서 누군가 또 코드를 잘못 썼으면?.. 그리고 매번 이런 과정을 거쳐야 한다면?..

누군가 이상한 코드를 말도 없이 바로 develop 브랜치에 push 했으면?..

그 외에도 여러 골칫거리 상황이 발생할 수 있다. 특히나 프로젝트 경험이 없는 팀원이 있거나, 팀원들과 커뮤니케이션이 잘 안되는 상황이면 더욱 더...

 

그래서 이러한 상황을 방지하고 효율적인 협업을 진행하기 위해 PR을 쓰는 것이다.

 

PR 사용법

이제 PR의 중요성을 알게 됐으니 사용 방법을 알아보자!

 

다음과 같이 To-do를 만드는 프로젝트를 하고 있다고 하자.

근데 할 일 목록 디자인이 맘에 안드는 상황이다.

이제부터 feature/to-do-list 브랜치에서 CSS를 수정하고, 이를 develop 브랜치에 병합하도록 요청을 할 것이다.

기존에 있는 할 일 목록 디자인은 위와 같이 되어 있었는데, 아래와 같이 수정을 해서 원격에 올린 상황이다.

그러면 github에 위와 같이 feature/to-do-list 브랜치가 몇 분 전에 push가 됐다는 요소가 뜬다.

PR을 하려면 해당 Compare & pull request 버튼을 눌러도 되고, 위에 있는 Pull Requests 탭을 클릭해도 된다.

1. base(받는 브랜치)와 compare(보내는 브랜치)을 알맞게 설정해준다.
2. 제목, 내용을 작성해준다. 내용은 성심성의껏, 무엇을 어떻게 변경했는지, 왜 변경했는지 작성해준다.
3. Option을 설정한다. 리뷰 해줄 사람(Reviewers), PR 승인 권한을 가지는 사람(Assignees)정도 설정하면 된다. 
4. 다 설정 했으면 Create pull request 버튼을 눌러 PR을 생성한다. (3번에 설정한 사람들에게 메일로 알림이 가게 된다.)

해당 과정을 따랐으면 다음과 같이 PR이 생성된다.

 

File changed 탭에 들어가면 수정된 내용을 볼 수 있다. 

해당 탭에서 코멘트를 남길 수 있다. 코멘트하고 싶은 코드를 클릭하거나 드래그하면 할 수 있다.

(부계정으로 전환해 코멘트를 남겨봤다.)

 

코멘트를 다 남겼으면 Finish your review 버튼을 클릭해 리뷰를 마칠 수 있다.

작성한 코멘트(코드 리뷰)에 대한 내용, 피드백 등의 내용을 쓰고 리뷰 타입을 설정한다.

• Comment: 코드에 대해 리뷰만 하는 경우
• Approve: 코드 리뷰 후 해당 피드백에 대해 고쳤거나 완벽해서 PR을 승인한다는 경우
• Request Changes: 코드를 고쳐야 하는 경우 

Subnut review 버튼을 누르면 Conversation 탭에 다음과 같은 내용이 추가된다.

이를 확인한 PR 요청자인 나는, 코멘트를 기반으로 코드를 수정해서 commit하고 원격에 올렸다. 그러면 자동으로 해당 PR 내용에 적용이 된다. 

 

Merge pull request를 누르면 PR이 승인 되어, PR 받는 브랜치(여기서는 develop)에 병합이 된다. 

 

 

마무리

PR을 사용하면 협업하면서 발생할 수 있는 여러 문제점들을 방지할 수 있고 체계적으로 진행할 수 있음을 알게되었다.

다음 글에서는 추가적으로 개발하면서 유용하거나 알면 좋을, 팀 프로젝트 하면서 알아야 할 git 명령어 등에 대해 다루고자 한다.