Github 3 - Pull Request(Code review)

5England·2021년 10월 3일
0

협업과 통합

목록 보기
6/12
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
한 눈에 보기 : https://velog.io/@dongwan999/LIST

0개의 댓글