Github 3 - Pull Request(Code review)

don9wan·2021년 10월 3일
0

협업과 통합

목록 보기
6/13
post-thumbnail

Pull Request?

  • Code Review의 핵심적인 기능이다.
  • 작업을 끝내고 merge 직전에 코드리뷰를 받아야 한다. 작업 진행 중이더라도 괜찮다. 코드 리뷰를 받을 수 있다. 이럴 때 사용하는 기능이 pull request, 사실 merge request라는 표현이 좀 더 적절하다.
  • 당신이 작업을 끝내고 develop 브런치, 즉 원격 레포지토리의 메인 브런치와 병합하기 전 pull request 버튼을 누르면
    • remote에 당신의 코드가 올라가고, 사람들이 검토 및 토론을 할 수 있게 된다.

"merge 전 검토(code review)를 통해 기본 브런치의 안정성을 높이는 것이 핵심이다."

0. pull request는 크게 두 가지 종류로 나뉜다.

  • 해당 remote에 권한이 있는 경우
    • merge 전 code review를 받기 위해
  • 해당 remote에 권한이 없는 경우
    • open source fork 후 작업한 뒤 merge 요청

1. me : pull request 만들기
1. commit에서 pull request를 누르거나, 직접 pull request를 만들거나
2. code reviewers 선택
3. 이하 create issue과 비슷
4. 두 가지 타입 선택

  • pull request : 작업이 끝나서 code review 후 merge
  • draft pull request : 작업이 끝나진 않았지만 code review 요청

2. reviewer : code review

  1. changed에서 +를 누르거나(1 line) +를 드래그해서(n line) 코멘트를 작성 후
  • add single comment : 단일 코드 리뷰 전송
  • Start/add a review : 그룹핑 리뷰 작성 시작/추가
    • Finish your review : 그룹핑 리뷰 작성을 마치고 전송
  1. suggested change로 내가 작성한 코드를 공유하는 기능도 있음
  2. comment/approve/request changes 선택해서 submit review!
  3. commit suggestion이라는 기능이 있다.
  • reviewer는 해당 기능을 통해 A->B 식으로 코드 변경사항을 작성한다.
  • 이후 나중에 리뷰 대상자가 코드 수정 시, commit changes 누르면 자동으로 해당 변경사항 커밋하는 기능도 있음
  • 근데 이걸 무작정 누르는게 좋은 건 아닌 것 같다.(개인적인 생각)

me : before merge(+conflict!)

  • 동일한 코드의 변경 사항이 push되면 충돌이 일어난다.
  • 이를 github는 감지하고 있으며, code review 중에도 이를 알려주고 자동으로 merge를 막는다.
  • 이 때 web editor를 통해 양쪽의 변경사항을 간단하게 파악하고, 코드를 채택해 merge 단계로 넘어갈 수 있다.
  • 하지만 github의 web editor는 제약이 많다.
  • 직접 수정하는 방법이 존재하는데, 이는 github에서 알려준다.

me : merge
1. 각 해당 브런치의 내용들을 검토 후 Merge pull request 클릭하면 Merge가 성공적으로 된다.
2. 로컬 레포지토리의 브런치인 master에서 git pull을 하게 되면 원격 레포지토리와 동기화된다.

profile
create services that help people make better choices with less time.

0개의 댓글