튜토리얼: 병합 요청 검토

병합 요청 검토는 코드베이스에 높은 품질의 코드만이 포함되도록 하는 데 도움을 줍니다. 이 튜토리얼에서는 GitLab에서 병합 요청을 검토하는 방법을 보여줍니다. 먼저 병합 요청의 구조를 안내하고, 건설적이고 도움이 되는 피드백을 제공하는 과정을 안내합니다. 튜토리얼 마지막에는 병합 요청을 승인하거나 추가 변경을 요청할 준비가 됩니다.

전반적인 내용은 병합 요청 검토를 참조하세요.

병합 요청을 검토하려면:

  1. 병합 요청으로 이동
  2. 병합 요청의 구조 이해
  3. 높은 수준의 개요 확인
    1. 관련 이슈 확인
    2. 사이드바 확인
    3. 코멘트 확인
  4. 코드 변경 내용 읽기
    1. 개요를 위한 변경 사항 빠르게 검토
    2. 각 파일 자세히 검토
    3. 코드 테스트
    4. 파이프라인 확인
    5. 재검토 고려 사항
    6. 큰 그림 고려
  5. 검토 마무리
    1. 검토 코멘트 작성
    2. 검토 요약
  6. 정리 작업 수행

병합 요청으로 이동

  1. 좌측 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 두 가지 방법 중 하나를 선택합니다:
    • 리뷰 요청 페이지로 이동하려면 Shift + r을(를) 누릅니다.
    • 좌측 사이드바에서 병합 요청 () > 리뷰 요청을 선택합니다.

병합 요청의 구조 이해

병합 요청에는 네 가지 옵션이 있는 보조 메뉴가 있습니다. 검토 과정에서 병합 요청의 이러한 영역을 다르게 사용합니다:

병합 요청 상단 영역 스크린샷, 네 개의 주요 탭이 표시됨

  • 개요: 병합 요청 설명, 현재 병합 가능성 보고서, 코멘트가 있는 활동 영역 및 상세 정보가 있는 사이드바가 있습니다.
  • 커밋: 이 병합 요청에 있는 커밋 목록으로, 가장 최근 커밋이 먼저 표시됩니다.
  • 파이프라인: 이 병합 요청 내용에 대해 실행된 CI/CD 파이프라인 목록입니다.
  • 변경 내용: 제안된 변경 내용의 차이로, 삭제된 라인, 추가된 라인 및 변경된 라인이 표시됩니다.

개요 탭의 사이드바에는 병합 요청 자체에 대한 중요한 메타데이터가 포함되어 있습니다: 담당자, 검토자, 라벨, 마일스톤, 시간 추적 등이 있습니다.

병합 요청의 높은 수준의 개요 확인

코드 검토에 뛰어들기 전에 병합 요청을 높은 수준에서 평가해야 합니다. 병합 요청의 맥락과 목적을 이해해야 하며, 이 요청이 무엇을 시도하고 있는지, 그 이유를 알아야 합니다. 이러한 요구 사항을 기술 세트와 비교하면서 다음 질문을 스스로에게 물어보세요:

  1. 병합 요청 뒤에 있는 이야기는 무엇인가요? 신중한 검토를 수행하기에 충분한 배경 지식이 있는가요?
  2. 요청된 검토의 유형과 심도는 무엇인가요? 예를 들어, 일부 요구 사항이 있는 좁은 범위의 버그 수정과 심층적 설계 검토는 매우 다른 검토 기대치를 가지고 있을 것입니다.
  3. 이 작업을 검토하는 것이 적절한가요? 요청된 검토 유형이 나의 기술과 능력과 일치하는지 확인하세요.

먼저 병합 요청 설명을 살펴보세요. 이는 이슈에서의 문제를 해결하거나 기능 요청을 해결해야 합니다.

  • 저자는 누구인가요? 이 사람의 작업에 익숙한가요? 이 사람을 알고 있다면, 일반적으로 이 사람이 어떤 부분의 코드 기반이 되는지 알아내세요. 이후에는 기존에 작성한 변경 사항을 어떻게 검토할지 판단하는 데 도움이 됩니다.
  • 목표는 무엇인가요? 설명을 읽고 저자의 의도를 이해하세요.
  • 드래프트인가요? 드래프트는 종종 불완전하거나 이론적인 솔루션입니다. 드래프트 병합 요청은 완전히 완성된 병합 요청과 다른 수준의 검토가 필요할 수 있습니다.
  • 문제를 재현할 수 있는 방법은 무엇인가요? 설명에서 문제를 재현하거나 변경 사항을 테스트하거나 새로운 기능을 시도할 수 있는 방법이 설명되어 있나요? 이것을 위한 스크린샷이 포함되어 있나요?

설명 아래에서 병합 요청 위젯을 확인하여 이 작업의 현재 상태를 이해하세요. 다음은 결함 승인이 누락된 병합 요청을 나타내는 병합 위젯의 예시입니다:

병합이 방지되는 여러 문제가 있는 병합 위젯

  • 이슈와 연결되어 있나요? 설명과 병합 위젯을 확인하여 다른 문제에 대한 링크가 있는지 확인하세요. 일부 병합 요청은 간단하지만, 일부는 해당 병합 요청의 이해를 위해 해당 이슈를 읽어야 할 수 있습니다. 복잡한 병합 요청은 자세한 정보가 있는 이슈로 되돌아가야 합니다.
  • 파이프라인 상태는 무엇인가요? 파이프라인이 초록색인가요? 빨간 파이프라인은 문제를 나타냅니다. 미완료 또는 취소된 파이프라인이 있는 경우 작업의 전체 병합 가능성을 평가할 수 없습니다.

관련 이슈 확인

관련된 이슈가 있고 병합 요청이 너무 복잡하여 더 많은 정보가 필요한 경우, 이슈 설명을 검토하세요.

  • 문제와 솔루션이 분리되어 있나요? 이슈는 문제를 설명하고 조사하고, 병합 요청은 해결책에 집중해야 합니다.
  • 병합 요청 저자가 이슈에 관여하고 있나요? 검토 과정 중에 문제 정의(또는 기능 정의)에 도움을 준 사람을 생각해보세요. 이상적으로는 해당 병합 요청에도 이들 사람이 관여해야 합니다.

사이드바 확인

  • 어떤 레이블이 있나요? 레이블은 병합 요청의 내용을 나타낼 수 있습니다. 팀의 작업 흐름에 따라, 미완료 또는 누락된 레이블은 무해할 수도 있고, 병합 요청에 완전한 정보가 부족하다는 것을 나타낼 수도 있습니다.
    • 레이블이 본인의 전문분야와 일치하는 경우, 이 병합 요청을 리뷰하는 좋은 후보입니다.
    • 레이블이 본인이 갖고 있지 않은 전문분야와 일치하는 경우, 병합 요청을 다른 리뷰어에게 재할당해야 할 수도 있습니다.
    • 워크플로우에서 요구하는 레이블을 추가하세요.

    이 예에서, 정확한 레이블이 익숙하지 않더라도, 데이터베이스 버그에 관한 병합 요처임을 확인할 수 있습니다:

    병합 요청에서 데이터베이스 레이블 예시

  • 리뷰어는 누구인가요? 리뷰어 목록의 이름을 스캔해보세요. 설명과 (선택사항으로) 레이블을 기반으로 예상하는 작업 유형과 일치하는지 확인하세요. 존재하는 사람뿐만 아니라 부재하는 사람도 고려하세요. 이러한 이름들이 병합 요청의 리뷰 주기에 대해 어떤 정보를 전달하나요? 추가하거나 제거해야 할 사람이 있는가요?
  • 어떤 리뷰어가 이미 승인했나요? 그러한 리뷰어들과 그들의 전문분야에 대해 알고 있다면, 제안된 변경 사항의 어떤 측면에 관심을 둘지에 대한 아이디어를 얻을 수 있습니다.

    이 예에서 Thomas와 Nick 두 명이 리뷰어입니다. Thomas는 아직 병합 요청을 리뷰하지 않았습니다 (). Nick은 리뷰하고 승인했습니다 ():

    f

코멘트 확인

개요 페이지에서, 작성자와 다른 사람들이 남긴 코멘트를 읽어보세요. 코드 변경 사항을 읽기 전에 이들 토론을 고려하세요.

코멘트에서 이전 리뷰의 증거가 보이시나요? 많은 코멘트는 이 작업을 얼마나 심층적으로 검토하고 싶은지에 영향을 줄 수 있습니다.

코드 변경 사항 읽기

이제 제안된 변경 사항을 읽을 준비가 되었습니다. 대규모 병합 요청의 경우, 깊게 들어가기 전에 변경 사항을 휘갈겨보세요. 변경 사항을 한 줄씩 읽기 전에 어떤 것을 기대해야 하는지 이해를 도모하세요.

참고: 변경 사항 탭에 표시된 차이점은 정보로 가득차 있습니다. 이 페이지에서 가장 많은 도움을 받으려면 병합 요청의 변경 사항을 참조하세요.

개요를 위한 변경 사항 휘갈기기

변경 사항 페이지를 처음 열었을 때, 먼저 전반적인 세부 사항에 집중하세요:

  • 어떤 파일이 변경되었나요? 파일 브라우저를 확장하세요 () 변경된 파일 목록을 보려면. 이러한 파일들이 익숙한가요? 이 파일들이 코드베이스의 어떤 부분에 속하는지 확인하세요.

    두 개의 변경된 파일을 보여주는 파일 트리 예시

  • 파일 목록이 기대와 일치하나요? 이미 병합 요청의 설명을 읽었습니다. 이러한 파일들이 이러한 종류의 작업을 위해 변경되었을 것이라고 예상하시나요? 예상치 못한 파일 변경에 특별한 주의를 기울이거나, 예상했던 변경이 누락된 경우에 주의를 기울이세요.
  • 추가된 줄, 제거된 줄, 또는 변경된 줄이 있나요? 이러한 숫자는 깊은 읽기에서 기대할 작업 유형을 알려줍니다: 새로운 기능, 제거된 기능, 또는 동작을 변경한 사항?
  • 테스트가 변경되었나요? 파일 중 테스트 스위트의 일부인 파일이 있나요? 그렇지 않다면, 작성자에게 테스트 업데이트를 요청해야 할 수 있습니다.
  • 기능 플래그가 사용되었나요? 기능 플래그를 확인하면 더 깊게 읽기 전에 기억해두세요.

변경 사항을 휘갈기는 작업이 끝나면, 줄 단위로 변경 사항을 읽을 준비가 된 것입니다!

각 파일을 자세히 조사

이제 병합 요청에 포함된 변경 사항에 대한 전반적인 아이디어가 생겼습니다. 이제 병합 요청의 변경 사항을 자세히 살펴보고 읽을 시간입니다. 과연 본인의 지식이 충분한 곳과 부족한 곳을 인식하며 접근하세요. 이 프로젝트를 잘 알고 계신가요? 변경 사항이 본인이 편안하게 작업할 수 있는 언어로 작성되었나요?

  • 변경 사항은 명확하고 이해하기 쉽나요?
  • 기능 플래그가 사용되었나요? 변경 사항이 기능 플래그의 존재 여부를 테스트하였나요? 기능 플래그가 비활성화된 경우 실수로 변경 사항이 누출되지는 않았는지 확인하세요.
  • 성능이 우수한가요? 성능 테스트를 직접 수행할 만큼 편안한가요, 아니면 보다 심층적인 성능 지식을 갖춘 리뷰어를 추가해야 할까요?
  • 간단하게 만들 수 있을까요?
  • 특이한 경우에 대비되어 있나요?
  • 주석 및 설명이 올바르게 작성되었나요? 좋은 코드는 작성자 뿐만 아니라 다른 사람들에 의해도 유지보수 가능해야 합니다. 이 작업을 유지보수 가능하게 만들 정도로 충분한 설명을 제공하였는지 확인하세요.
  • 팀의 스타일 기대를 준수하고 있나요?
  • 역호환성이 있는가요? 이 작업은 호환성을 유지하고 있나요? 데이터 손실을 일으킬 수 있는 중요한 변경 사항인가요?
  • 보안 문제가 고려되었나요? 변경 사항이 특별한 보안 고려 사항이 있는 프로젝트 영역에 있는지 확인하세요. 민감한 데이터를 적절하게 처리하고 사용자 입력을 받았는지 확인하세요. 더 많은 보안 지식을 갖춘 리뷰어를 추가해야 할까요?
  • 디버깅 문이 남아 있지는 않았나요?

다양한 유형의 변경 사항은 코드베이스에 다양한 영향을 미칩니다. 전반적으로 고려해보세요:

  • 추가된 줄: 새로운 코드는 기존 동작을 수정해서는 안 됩니다. 새로운 동작에 대한 테스트는 되어 있나요? 테스트가 충분히 세분화되었나요?
  • 제거된 줄: 삭제가 청소되고 완전한가요? 제거된 코드와 테스트가 서로 범위상 일치하는지 확인하세요. 어느 한 곳에도 부분적인 스텁이 남아있지 않도록 확인하세요.
  • 수정된 줄: 추가된 줄과 제거된 줄이 거의 동일하다면, 변경 사항은 기존 코드의 리팩토링인가요? 리팩토링인 경우, 이전 코드가 무엇을 하고 새 코드가 어떻게 다르게 작동하는지 이해했나요? 변경된 동작이 작성자의 명시적인 의도와 일치하는지 확인하세요. 테스트가 여전히 올바르게 작동하는지 확인하세요.

코드 테스트

불행히도, 이 부분에서는 많은 안내를 제공할 수 없습니다. 모든 프로젝트가 다릅니다! 본인의 응용 프로그램을 직접 알지 못하면 변경 사항을 어떻게 테스트할지를 알려드릴 수 없습니다. 하지만 고려해야 할 몇 가지 질문을 제공할 수 있습니다:

  • 정상 작동하는가요? 간단한 질문이지만 중요합니다. 코드는 못생기거나 복잡할 수 있지만, 여전히 작동해야 합니다.
  • 리뷰 프로세스는 어디에 있는가요? 리뷰 프로세스의 초기 또는 후반인가요? 전문가인가요?

    • 프로세스 초기에 있는 리뷰어는 작성자가 말한 대로 코드가 작동하는지 검증해야 합니다. 이렇게 하면 더 많은 사람들이 병합할 수 없거나 병합해서는 안 되는 코드에 시간을 헛될이하지 않습니다.
    • 프로세스 후반에 있는 리뷰어는 기능이 광고대로 작동하는지 확인하는 데 관여하지 않을 수도 있지만, 대신 스타일과 유지보수에 더 집중할 수 있습니다.
    • 전문 리뷰어는 병합 요청의 특정 부분만 리뷰할 수 있으며 전체 병합 요청이 예상대로 작동하는지에 대해 다료지 않을 수도 있습니다.

코드를 테스트하는 동안, 파이프라인 상태도 확인해야 합니다. 아직 리뷰 코멘트를 작성하지 않았지만, 거의 완료되었습니다.

파이프라인 확인

병합 요청의 파이프라인 탭으로 이동하여 파이프라인 상태를 확인합니다. 파이프라인이 성공한 경우에만 병합 요청을 승인합니다. 이 예에서 여러 작업이 실패했습니다:

Widget showing a failed pipeline, with passing jobs in green and failed jobs in red

  • 예상한 테스트가 모두 실행되었나요? 파이프라인이 단순히 초록색이 아니라 완료된 것을 확인합니다.
  • 어떤 테스트가 실패했나요? 실패한 작업이 있는지 확인하려면 실패한 작업을 확장합니다.
  • 각 실패한 작업에서 무슨 일이 발생했나요? 실패한 각 작업을 선택합니다. 결과를 스캔하여 실패, 오류 및 빨간색으로 표시된 줄을 찾습니다. 리뷰 코멘트를 작성할 때 작성자가 무엇을 고쳐야 하는지, 그리고 어떻게 고쳐야 하는지 이해할 수 있도록 돕고자 합니다.
  • 실패가 변경 사항과 관련이 있나요? 실패가 관련이 없는 것으로 보인다면 작업 또는 파이프라인을 다시 실행하는 것을 고려합니다.

재검토 고려 사항

가끔 병합 요청 검토는 직접적이지 않고 지시자와 리뷰어 간의 소통이 필요합니다. 작업을 다시 검토할 경우 이 병합 요청에 대한 커밋 페이지로 이동하고, 마지막으로 리뷰한 후 추가된 커밋 내용을 읽습니다.

이 커밋들이 초기 리뷰에서 발견한 사항을 해결하고 있는지 확인하세요.

큰 그림을 고려해보세요

자세하고 도움이 되는 리뷰를 위해 준비 작업을 마쳤습니다. 병합 요청을 처음 훑어볼 때는 라인 레벨의 변경 사항에 대한 전체 지식이 없었습니다. 이제 전체적으로 이해했습니다! 리뷰를 시작하기 전에 라인별로 내려보지 말고 다시 넓은 시각으로 생각해 보세요. 이제 병합 요청이 무엇을 시도하고 있는지, 그리고 어떻게 시도하고 있는지 알고 있습니다.

  • 병합 요청의 변경 사항이 의도한 범위와 일치하나요? 그렇지 않다면 작업을 단순화해야 할지, 아니면 여러 병합 요청으로 분할해야 할지 고민하세요. 자신의 지식 범위와 한계에 대해 솔직하게 생각하고 진지하게 다가갑니다.
  • 코드 스멜을 감지했나요? 보고 있는 것이 버그는 아니지만 향후 품질, 유지보수 또는 보안 문제를 가리킨다면 주의깊게 확인하세요. 변경 사항에 뭔가 이상하거나 불분명하게 느껴진다면 직감을 믿으세요. 코드는 기술적으로 정확할 수 있지만 향후 문제를 일으킬 수 있는 약점이 있을 수 있습니다.

가장 좋고 도움이 되는 코드 검토는 라인별 수정 사항에만 초점을 맞추지 않습니다. 유지 관리성 및 기술 부채와 같은 장기적인 문제에 대해서도 고려합니다.

리뷰 완료하기

의견을 제공할 시간입니다!

병합 요청을 검토하는 것이 처음이라면, 첫 댓글을 작성하기 전에 생각하는 데 얼마나 많은 시간을 소비하는지 놀랄 것입니다. 코드 베이스가 익숙해지면 새로운 병합 요청을 더 빨리 이해할 수 있을 것입니다. 그러나 - 아마도 더 복잡한 리뷰를 맡게 될 가능성도 있습니다.

리뷰 코멘트 작성

리뷰 시작 기능을 사용하여 보류 중인 코멘트를 작성할 수 있습니다. 이러한 코멘트는 리뷰를 제출할 때까지 다른 사람에게는 표시되지 않습니다. 이를 통해 수신자에게 메시지가 과도하게 전달되는 것을 피하고, 게시하기 전에 각각의 말을 다시 확인하고(변경하고) 기회를 얻을 수 있습니다.

건설적이고 친절하게 작성하세요. 관행적인 코멘트의 구조는 신중하고 건설적인 코멘트를 작성하는 데 도움이 될 수 있습니다.

먼저, 특정 라인 또는 파일에 첨부하려는 코멘트를 작성합니다:

  1. 변경 탭을 선택합니다.
  2. 질문하거나 피드백을 제공하고 싶은 라인을 찾으면 번호표에 있는 이 라인에 코멘트 추가()를 선택합니다. 이렇게 함으로써 차이점을 확장하고 코멘트 상자가 표시됩니다.
  3. 여기서 다중의 라인을 선택하거나 코멘트를 달 파일 전체를 선택할 수 있습니다:

    단일 라인 또는 여러 라인에 코멘트 작성

  4. 텍스트 영역에 첫 번째 코멘트를 작성합니다. 리뷰가 끝날 때까지 코멘트를 비공개로 유지하려면 코멘트 아래에 있는 리뷰 시작을 선택합니다.
  5. 코드 변경 내용이 작성하기 쉬운 경우나 작성자가 더 나은 접근 방법을 보게 하고 싶은 경우 제안을 제공하세요. 코드 변경 사항이 너무 크거나 복잡해 경우 변경을 요청하는 코멘트를 남겨주세요.
  6. 파일 및 개별 코드 라인에 대한 코멘트 작성을 계속합니다. 각 코멘트 후에 리뷰에 추가를 선택합니다.

일하는 동안 빠른 조치/label 또는 /assign_reviewer와 같은 것을 코멘트로 사용할 수 있습니다. 보류 중인 코멘트에 요청한 작업이 표시되지만 리뷰를 제출할 때까지 작업을 수행하지 않습니다. (나중에 /submit_review 빠른 조치를 사용하여 리뷰를 제출할 수도 있습니다!)

리뷰 요약

파일 및 라인별 피드백을 추가했으므로 이제 리뷰를 요약할 준비가 되었습니다. 한 번 더 넓은 시야에서 생각하는 시기입니다.

  1. 병합 요청의 개요 페이지로 돌아갑니다.
  2. 보류 중인 코멘트를 검토합니다. 도움이 되고 신중하며 친절하고, 가장 중요하게 _조치 가능_해야 합니다. 찾은 문제를 해결하는 명확한 다음 단계를 작성했나요?
  3. 어조를 고려합니다. 가르치거나 토론하거나 토의하고 있나요? 코멘트가 목표를 달성했나요? 작성자라면 다음에 무엇을 해야 할지 알게 되었나요? 좋은 행동을 강조하고, 나쁜 행동에서 멀어지도록 작성자를 격려하세요.
  4. 코멘트가 여전히 유효한가요? 큰 병합 요청에서는 몇 가지 코멘트가 더 이상 유용하지 않거나 중간에 제기한 몇 가지 질문이 중간에 이미 대답된 경우가 있을 수 있습니다.
  5. 일반화된 피드백을 위한 쓰레드 시작합니다. 관련 없는 항목이 동일한 코멘트에 모여 있지 않도록되도록하여 쓰레드가 해결되면 미처 다루지 않은 피드백이 숨겨지지 않도록 합니다. 몇 가지 가능한 주제:
    • 큰 함수를 작은 단일 목적 함수로 분할.
    • 의미 있는 변수 이름 사용.
    • 복잡한 코드를 설명하기 위해 더 많은 주석 추가.
    • 특이한 경우와 오류 확인.
  6. 요약 코멘트를 위한 새 쓰레드를 시작합니다. 작성자의 사용자 이름을 언급하여 신뢰할 수 있도록 작성하세요.
    • 전체적인 발견은 무엇입니까?
    • 리뷰를 마쳤습니까, 아니면 더 많은 작업이 완료된 후에 이 병합 요청을 다시 보고 싶습니까?
  7. 리뷰 제출을 선택하여 리뷰에 대한 모든 코멘트를 게시합니다. 리뷰를 제출하면 이러한 리뷰 코멘트에 포함된 빠른 조치가 실행됩니다.
    • 변경 사항이 좋아 보인다면 승인을 선택하세요.
    • 변경 사항이 더 많은 작업이 필요하다면 변경 요청를 선택하세요.

만약 병합 요청을 승인하고 리뷰어 목록에 표시된 경우, 녹색 확인 표시 이 이름 옆에 표시됩니다.

정리 작업 수행

의견을 제공한 후 정리하세요.

  • 보류 중인 모든 의견이 제출되었는지 확인하세요.
  • 라벨 및 마일스톤을 업데이트하세요.
  • 승인 요구 사항을 확인하세요.
    • 해당하는 모든 작업(백엔드, 프론트엔드, 문서)이 올바른 사람에 의해 검토되었는지 확인하세요.
    • 추가 검토가 필요한 경우, 다음 검토자의 사용자 이름을 언급하고, 그들을 검토자로 추가하세요.
  • 병합 위젯을 확인하세요.
    • 가능한 경우 블로커를 해결하고, 도와줄 사용자를 지정하세요.
    • 검토를 위해 필요한 코드 소유자를 추가하세요.
  • 이 병합 요청을 병합할 준비가 되었나요? 병합 요청이 완전히 검토되고 승인되었다면, 유지자에게 할당하세요!

관련 주제