[TIL] 스파르타) Project 3 - 2일차, Github Pull Request, review, 그 외 팀 프로젝트 관련 사항들

 

 > 팀 프로젝트 진행 2일차로 코드 작성 및 Github pull request를 팀원들과 함께 진행했다.

 

학습 키워드: javascript, CSS, Github, git, pull request, review, merge conflict

 

1. Github Pull Request 와 Reviewer

1) What is it?:

 - git에서 merge는 로컬에서 진행하는 방법도 있지만 협업 중에는 Github의 Pull Request를 사용해야 한다. Pull Request는 다른 branch를 본 branch에 pull 하여 합치는 과정으로, merge와 동일한 작업이지만 프로젝트 설정에 따라 중간에 여러가지 merge 승인 과정이 추가된다.

 

2) How does it work?:

 - 프로젝트의 repository에서 상단의 Pull Request 탭에 진입하여 New Pull Request 버튼을 누르면 새로운 pull request를 생성할 수 있다. base branch와 compare branch 명을 잘 확인하고 작성해야 한다.

 - pull request의 우측 사이드바에서 여러가지 항목들을 설정해줄 수 있는데, 그 중 reviewers를 이번 프로젝트에서 처음 활용해보았다.

 - Reviewers: 이 pull request를 검토해 줄 사람들을 선택하여 등록할 수 있다. 등록된 인원은 이 pull request 페이지에 진입하면 우측 상단에 review를 작성할 수 있는 녹색 버튼이 생성된다. 버튼을 누르면 대상 branch와 베이스 branch를 비교하여 변경점을 체크하는 화면으로 진입하는데, 코드 블럭을 대상으로 comment를 작성하여 request 작성자에게 확인을 요청할 수도 있다. Commenting이 완료되면 우측 상단에서 이 request를 승인할지 거부할지를 정할 수 있다.

 - 앞서 말했듯이 프로젝트의 branch 설정을 통해 어떤 branch로 pull request를 시도할 때 몇 명의 reviewer의 승인이 필요할지를 미리 설정할 수가 있다. 리포지토리 상단 메뉴의 settings를 누르고 진입하여 좌측 사이드바에 있는 Branches 에서 branch 이름과 어떤 방식으로 동작할지 등의 rule을 작성하여 추가하면 된다. 규칙은 여러 개를 추가할 수 있고, 승인 기능 외에도 branch를 read-only로 바꾸는 등 다른 여러가지 branch 보호 규칙들이 있으니 살펴보고 설정해두면 좋다.

 

 

3) Why use it?:

 - 협업 개발에서 누군가가 잘 못 수정한 코드를 핵심 branch에 merge해버리면 대참사가 일어난다. Revert나 reset처럼 변경 사항을 되돌리는 방법들이 존재하기는 하지만, deploy된 branch를 대상으로 벌어지는 경우 또한 있을 수 있으니 미리 github의 repository 설정에서 branch 보호 설정을 걸어두고 pull request를 통해 검토한 후 안전하게 merge 하도록 하는 것이 올바른 방법이다.

 

2. 그 외 팀 프로젝트 관련 사항

 - 오늘 발생한 문제는 바로 merge 과정에서 깨닫게 된 code formatting 공유의 중요성이다. 개발자마다 formatting을 하는 스타일이 다 다르기 때문에 팀 프로젝트를 진행하면서 이를 미리 맞춰두지 않으면 오늘처럼 누군가가 에디터의 자동 formatting 기능을 사용할 때 마다 모든 코드가 변경점으로 기록되는 참사가 일어난다. 해서 가능하면 이번 프로젝트나 다음 팀 프로젝트부터는 시작 전에 미리 에디터 자동 formatting을 협의하여 똑같이 맞춰야겠다는 교훈을 얻었다.

 

 

--

 

REFERENCES:

 

GitHub - donkim1212/nbc_ch2_tmdb: 스파르타) JavaScript Project 3

 > 13팀 JS 팀 프로젝트 Repository, issue와 pull request 작성 기록 확인