[Chapter 3] repository 협업(7) - Pull Request

 

 

지금까지 병합 과정에서, 우리는 몇 가지 원칙을 만들어 운영한다고 했습니다. 애초에 마스터 브랜치에 직접 커밋을 진행하지 않고, 피처 브랜치를 만들어 병합하는 것 자체도 일종의 사고 방지를 위한 대원칙입니다.

 

다만, git의 기능 레벨에서 이러한 절차를 보강할 필요가 있겠죠? 피처 브랜치에서 마스터 브랜치로 병합하는 과정에서도, 협력자가 사전에 검토할 수 있도록 사전에 확인 과정을 거치는 기능이 바로 풀 리퀘스트(Pull Request)입니다. 

 

우선 기존 실습 환경에서, 새로운 피처 브랜치를 하나 생성하고 커밋하는 과정에서 풀 리퀘스트를 사용하며 배워보도록 하겠습니다.

 

 

---

 

 

우선 기존까지 진행된 작업물의 상태에서 새로운 피처 브랜치를 생성해 보겠습니다. [feature/memo] 브랜치를 생성해서 새로운 커밋까지 만들어 보겠습니다. 

 

우선 마스터 브랜치로 체크아웃되어 있는 상태에서(주의!) 새로운 브랜치 [feature/memo]를 생성합니다. 그리고 로컬 저장소에서 "memo.md"를 추가 생성하여 '유저정보 메모 기능'이라는 텍스트를 한 줄 작성해 저장하고 커밋한 다음 푸시까지 완료해 보도록 합시다.

 

[feature/memo] 브랜치 생성 후 커밋, 푸시까지 완료했습니다

 

 

 

---

 

 

 

이제 github 웹 페이지로 들어가서 현재 상태를 확인해 보겠습니다. 상단에 [feature/memo] 브랜치에 새로운 푸시가 적용되었다는 메시지와 [Compare & pull request] 버튼이 노출됩니다. 이것을 클릭해 보겠습니다.

 

 

 

 

아래와 같이 풀 리퀘스트 생성 화면이 나타났습니다. 각각의 기능을 하나씩 짚어보겠습니다.

 

 

- base : 우리가 병합을 하려고하는 대상 브랜치입니다. 마스터로 병합하고자 하므로, [master]를 선택합니다.

- compare : 베이스 브랜치에 적용할 브랜치입니다. [feature/memo] 브랜치를 선택합니다. 

- 풀 리퀘스트 제목 + 내용 : 커밋 당시 작성한 내용이 적용됩니다. 하단의 텍스트 사항에는 상세 설명을 기재합니다. 

- 'Able to merge' : 두 브랜치를 비교하여, 충돌이 있는지 검사한 결과입니다. 현재는 이상이 없으며 문제가 발생하면 conflict가 출력됩니다.

- Reviewers : 해당 풀 리퀘스트를 검토할 대상자를 지정할 수 있습니다. 

- Assignees : 해당 풀 리퀘스트의 담당자로, 대부분 자기 자신입니다. 

- Labels : 합의된 라벨을 부여합니다. [버그], [신규기능], [서버]...

 

작성이 완료되었다면 하단의 [Create pull request]를 클릭합니다.

 

 

---

 

 

하단의 이미지와 같이 풀 리퀘스트 스레드가 생성됩니다. 여기서 리뷰어가 이 내용을 확인하고 검토를 진행하며, 코드 라인과 관련해 토론을 진행할 수 있습니다. 일단은 초록색 [Merge pull request]를 클릭해 병합을 진행해 보겠습니다.

 

풀 리퀘스트 내용을 검토한 후

 

병합까지 완료되었습니다

 

 

완료된 풀 리퀘스트는 Pull Request 탭에서 다시 확인이 가능합니다. 

 

 

---

 

 

브랜치 병합이 github 웹 페이지에서 완료되었지만, 실제 소스트리에서는 아직 적용되지 않았습니다. 이때 [패치]를 통해서 이력을 업데이트해야 합니다. 

 

패치를 실행합니다

 

 

 

 

패치를 완료하면, 아래 그림과 같이 상태가 변경됩니다. origin 마스터 브랜치의 경우 최신 버전으로 업데이트 된업데이트된 상태이며, 로컬의 마스터 브랜치는 두 단계 이전의 커밋 상태에 태그가 머물러 있는 것이 표시됩니다. 팝업 피처 브랜치가 업데이트된 시점이죠.

 

 

 

 

이제 마스터 브랜치로 체크아웃하여 Pull을 진행합니다. 

마스터 브랜치로 체크아웃 후 pull을 진행합니다

 

 

로컬 저장소의 마스터 브랜치까지 모두 적용되었습니다