튜토리얼: 병합 요청 검토하기

병합 요청 검토는 고품질 코드만 코드베이스에 통합되도록 보장하는 데 도움을 줍니다.

이 튜토리얼은 GitLab에서 병합 요청을 검토하는 방법을 보여줍니다.

병합 요청 자체의 구조와 건설적인 유용한 피드백을 제공하는 과정을 안내합니다.

튜토리얼이 끝날 때쯤에는 병합 요청을 승인하거나 더 많은 변경을 요청할 준비가 되어 있을 것입니다.

개요는 병합 요청 검토를 참조하세요.

병합 요청을 검토하려면:

병합 요청으로 이동하기
병합 요청의 구조 이해하기
전체적인 개요 얻기
코드 변경 사항 읽기
검토 마무리하기
1. 검토 댓글 작성하기
2. 검토 요약하기
정리 작업 수행하기

병합 요청으로 이동하기

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
다음 중 하나를 선택합니다:
- Shift + r를 눌러 검토 요청 페이지로 이동합니다.
- 왼쪽 사이드바에서 병합 요청 () > 검토 요청을 선택합니다.

병합 요청의 구조 이해하기

병합 요청에는 네 가지 옵션이 있는 보조 메뉴가 있습니다.

검토하는 동안 병합 요청의 이러한 영역을 다르게 사용할 것입니다:

개요: 병합 요청의 설명, 현재 병합 가능성에 대한 보고서, 댓글이 있는 활동 영역, 그리고 추가 정보가 있는 사이드바.
커밋: 이 병합 요청의 커밋 목록, 최신 커밋이 가장 먼저 표시됩니다.
파이프라인: 이 병합 요청의 콘텐츠에 대해 실행된 CI/CD 파이프라인 목록.
변경 사항: 이 병합 요청에서 제안된 변경 사항의 차이(difference)를 보여주는 내용으로, 삭제된 줄, 추가된 줄, 변경된 줄을 나타냅니다.

개요 탭의 사이드바에는 병합 요청 자체에 대한 중요한 메타데이터가 포함되어 있습니다:

담당자, 검토자, 레이블, 마일스톤 및 시간 추적.

병합 요청에 대한 높은 수준의 개요

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

병합 요청의 배경 이야기는 무엇인가요? 이 영역에 대한 충분한 배경 지식이 있어서 신중한 검토를 수행할 수 있나요?
어떤 유형과 깊이의 검토가 요청되었나요? 예를 들어, 좁은 범위의 버그 수정과 깊이 있는 아키텍처 검토는 아마도 매우 다른 검토 기대치를 가질 것입니다.
이 작업을 검토할 적합한 사람인가요? 필요한 검토 유형이 귀하의 기술 및 능력과 일치하나요?

병합 요청의 설명을 살펴보는 것으로 시작하세요. 이는 문제에 대한 해결책이나 문제에서의 기능 요청이어야 합니다.

작성자는 누구인가요? 이 사람의 작업에 익숙한가요? 이 사람과 잘 아는 경우, 그들이 보통 작업하는 코드베이스의 부분은 무엇인가요? 나중에, 작성자에 대한 지식은 그들의 변경 사항을 검토하는 데 도움을 줍니다.
목표는 무엇인가요? 설명을 읽어 작성자의 의도를 이해하세요.
초안인가요? 초안은 종종 불완전하거나 이론적인 해결책입니다. 초안 병합 요청은 완전히 완료된 병합 요청과는 다른 수준의 검토가 필요할 수 있습니다.
문제를 어떻게 재현할 수 있나요? 설명에 문제가 재현되는 방법, 변경 사항을 테스트하는 방법, 또는 새 기능을 시도하는 방법을 설명하고 있나요? 가이드를 제공하는 스크린샷이 포함되어 있나요?

설명 아래에서 병합 요청 위젯을 확인하여 현재 이 작업의 상태를 이해하세요. 이 예시에서는 승인이 부족하고, 아직 초안 모드이며, 해결되지 않은 토론 스레드가 있는 병합 요청을 보여줍니다:

이슈와 교차 링크가 있나요? 설명과 병합 위젯에서 다른 이슈에 대한 링크를 확인하세요. 일부 병합 요청은 간단하지만, 일부는 해당 병합 요청이 어떻게 생겼는지 이해하기 위해 해당 이슈를 읽어야 합니다. 더 복잡한 병합 요청은 전체 정보를 가진 이슈로 다시 연결되어 있어야 합니다.
파이프라인 상태는 어떤가요? 파이프라인이 초록색인가요? 빨간색 파이프라인은 문제를 나타냅니다. 미완료 또는 취소된 파이프라인이 보이면, 작업의 전체 병합 가능성을 평가할 수 없습니다.

사이드바 확인

어떤 레이블이 붙어 있나요? 레이블은 병합 요청의 내용을 제공하는 단서가 될 수 있습니다. 귀하의 팀의 워크플로에 따라, 불완전하거나 누락된 레이블은 무해할 수 있거나 이 병합 요청이 전체 정보를 부족하다는 것을 나타낼 수 있습니다.
- 레이블이 귀하의 전문 분야와 일치한다면, 귀하는 이 병합 요청을 검토할 좋은 후보일 가능성이 높습니다.
- 레이블이 귀하의 전문 분야와 일치하지 않는 경우, 병합 요청을 다른 검토자에게 재배정해야 할 수도 있습니다.
- 귀하의 워크플로에서 기대하는 레이블을 추가하세요.
이 예시에서는, 정확한 레이블이 귀하에게 낯설더라도, 이 병합 요청이 데이터베이스 버그에 관한 것임을 판단할 수 있습니다:
검토자는 누구인가요? 검토자 리스트에서 이름을 살펴보세요. 설명과 (선택적으로) 레이블을 바탕으로 예상되는 유형의 작업과 일치하나요? 어떤 사람이 있는지와 어떤 사람이 없는지 모두 고려하세요. 이 이름들이 병합 요청이 검토 주기에서 어디에 있는지를 무엇을 말해주나요? 누군가를 추가하거나 제거해야 하나요?
검토자가 이미 승인했나요? 이러한 검토자와 그들의 전문 분야를 알고 있다면, 제안된 변경 사항의 어떤 측면에 귀하의 주의가 필요한지에 대한 아이디어를 얻을 수 있습니다.

이 예시에서는 Thomas와 Nick이 검토자입니다. Thomas는 아직 병합 요청을 검토하지 않았습니다 (). Nick은 병합 요청을 검토하고 승인했습니다 ():

댓글 확인

개요 페이지에서 작성자 및 다른 사람들이 남긴 댓글을 읽어보세요.

코드 변경 내용을 읽으면서 그러한 논의를 염두에 두세요.

주석에서 이전 리뷰의 증거를 볼 수 있나요? 많은 수의 댓글은 이 작업을 얼마나 깊이 검토하고 싶은지에 영향을 미칠 수 있습니다.

코드 변경 사항 읽기

이제 제안된 변경 사항을 읽을 준비가 되었습니다. 큰 병합 요청의 경우, 세부 사항에 들어가기 전에 변경 내용을 훑어보세요.

변경 내용을 한 줄씩 읽기 시작하기 전에 무엇을 기대할 수 있을지 이해를 쌓으세요.

참고: 변경 사항 탭에 표시된 차이는 정보가 풍부합니다. 이 페이지를 최대한 활용하는 방법에 대해 알아보려면 병합 요청의 변경 사항을 참조하세요.

개요를 위한 변경 사항 훑어보기

변경 사항 페이지를 처음 열었을 때, 먼저 더 넓은 세부 사항에 집중하세요:

어떤 파일이 변경되었나요? 파일 브라우저()를 확장하여 변경된 파일 목록을 확인하세요.

이 파일들이 익숙한가요? 이 파일들이 어떤 코드베이스에 있나요?
파일 목록이 예상과 일치하나요? 이미 병합 요청의 설명을 읽었습니다.

이 종류의 작업에 대해 변경된 파일이 이러한 파일들이 맞나요? 예기치 않은 파일의 변경 사항이나 기대했던 변경 사항이 누락된 경우 주의하세요.
라인이 추가, 제거 또는 변경되었나요? 이러한 숫자는 깊이 읽기에 대해 기대할 수 있는 작업의 종류를 보여줍니다: 새로운 기능, 제거된 기능, 또는 동작의 변화?
테스트가 변경되었나요? 파일 중 어떤 것이 테스트 스위트의 일부인가요?

그렇지 않은 경우, 작성자가 테스트를 업데이트하도록 유도해야 할 수도 있습니다.
기능 플래그가 사용되었나요? 기능 플래그가 보인다면, 깊이 읽을 때 그 사용을 확인하도록 메모하세요.

변경 사항을 훑어보는 작업을 마친 후, 이제 변경 사항을 한 줄씩 읽을 준비가 되었습니다!

각 파일을 심도 있게 살펴보기

이제 이 병합 요청에 들어 있는 변경 사항에 대한 넓은 아이디어를 가지고 있습니다.

이제 깊이 있는 변경 사항을 전체적으로 읽을 시간입니다.

자신의 지식이 강한 부분과 약한 부분을 잘 인지하세요.

이 프로젝트를 잘 알고 있나요? 변경 사항이 자신이 편하게 다룰 수 있는 언어로 작성되어 있나요?

변경 사항이 명확하고 이해할 수 있나요?
기능 플래그가 사용되었나요? 변경 사항이 기능 플래그의 존재 또는 부재를 테스트하고 있나요?

기능 플래그가 비활성화될 때 기능 플래그의 변경 사항이 우발적으로 노출되지 않도록 해야 합니다.
성능이 뛰어난가요? 본인이 성능을 직접 테스트할 수 있나요, 아니면 성능에 대한 더 깊은 지식을 가진 리뷰어를 추가해야 하나요?
단순화할 수 있나요?
엣지 케이스를 고려하고 있나요?
올바르게 주석 처리되고 문서화되어 있나요? 좋은 코드는 다른 사람들에 의해 유지 관리 가능해야 합니다,

작성자뿐만 아니라요. 작성자가 이 작업을 유지 관리할 수 있도록 충분한 설명을 제공했나요?
팀의 스타일 기대 사항을 따르고 있나요?
역호환성이 있나요? 이 작업이 파괴적인 변경 사항인가요? 데이터 손실을 유발할 수 있나요?
보안 우려 사항이 해결되었나요? 변경 사항이 프로젝트의 보안 우려 사항이 있는 영역에 있나요?

민감한 데이터를 적절하게 처리하나요? 사용자 입력을 받고, 이는 정제되었나요? 보안에 대한 더 많은 지식을 가진 리뷰어를 추가해야 하나요?
디버깅 진술이 남겨져 있나요?

다양한 유형의 변경 사항은 코드베이스에 서로 다른 영향을 미칩니다.

넓은 관점에서 고려해보세요:

추가된 라인: 새로운 코드는 기존 동작을 수정해서는 안 됩니다.

새로운 동작이 테스트되었나요? 테스트가 충분히 세분화되었나요?
제거된 라인: 제거가 깨끗하고 완전한가요? 제거된 코드와 그에 따른

테스트가 같은 범위에 있나요? 어느 쪽에서도 부분적인 스텁이 남지 않도록 해야 합니다.
수정된 라인: 추가된 라인과 제거된 라인의 수가 대략 같다면,

변경 사항은 기존 코드를 리팩토링한 것인가요? 리팩토링의 경우, 이전 코드가 수행하던 작업과

새로운 코드가 그것을 어떻게 다르게 수행하는지 이해하고 있나요?

동작의 변화가 작성자가 설명한 의도와 일치하나요? 테스트는 여전히 제대로 작동하나요?

코드를 테스트하세요

안타깝게도, 여기에서 많은 지침을 제공할 수 없습니다. 모든 프로젝트는 다릅니다!

귀하의 애플리케이션에 대한 정보를 모르기 때문에 변경 사항을 어떻게 테스트해야 할지는 말씀드릴 수 없지만, 고려할 수 있는 몇 가지 질문을 제안할 수 있습니다:

작동 하나요? deceptively 간단한 질문이지만, 염두에 두는 것이 중요합니다. 코드는 지저분하고, 복잡하며, 문서화되지 않았을 수 있지만 — 여전히 작동할 수 있습니다.
검토 프로세스는 얼마나 진행되었나요? 검토 프로세스가 초기인가요, 아니면 후반인가요? 전문 분야에 속하나요?
- 프로세스 초반의 검토자는 저자가 코드가 작동해야 한다고 말한 대로 작동하는지 확인해야 합니다. 이렇게 하면 더 많은 사람들이 병합할 수 없거나 병합해서는 안 되는 코드에 시간과 노력을 낭비하는 것을 방지할 수 있습니다.
- 프로세스 후반의 검토자는 기능이 광고된 대로 작동하는지 확인하는 것에 관여하지 않을 수 있지만, 대신 스타일과 유지 관리성에 더 중점을 둘 수 있습니다.
- 전문 검토자는 병합 요청의 특정 부분만 검토하고, 전체 병합 요청이 예상대로 작동하는지 여부는 다루지 않을 수 있습니다.

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

파이프라인 확인

병합 요청의 Pipelines 탭으로 이동하여 파이프라인 상태를 확인하십시오.

파이프라인이 성공한 경우에만 병합 요청을 승인하십시오.

이 예제에서는 여러 작업이 실패했습니다:

모든 예상 테스트가 실행되었나요? 파이프라인이 단지 녹색인지가 아니라 완전한지 확인하십시오.
어떤 테스트가 실패했나요? Failed jobs를 확장하여 어떤 테스트가 실패했는지 확인하십시오.
각 실패한 작업에서 무슨 일이 발생했나요? 실패한 각 작업을 선택합니다. 출력을 스크롤하며 실패, 오류, 및 빨간색으로 표시된 줄을 살펴보십시오. 검토 의견을 작성할 때, 저자가 무엇을 수정해야 하는지, 그리고 어떻게 해야 하는지 이해하도록 돕고 싶습니다.
실패가 변경 사항과 관련이 있나요? 실패가 관련이 없는 것 같다면, 작업이나 파이프라인을 다시 실행하는 것을 고려하십시오.

재검토 고려 사항

때때로 병합 요청 리뷰는 간단하지 않으며, 담당자와 검토자 간의 상호작용이 필요합니다. 작업을 재검토하는 경우, 이 병합 요청의 Commits 페이지로 이동하여 마지막 검토 이후에 추가된 커밋의 내용을 읽으십시오.

이 커밋들이 초기 검토에서의 우려 사항을 해결하고 있나요?

큰 그림을 생각하세요

이제는 사려 깊고 도움을 주는 리뷰를 위한 준비 작업을 완료했습니다. 처음 병합 요청을 대충 살펴보았을 때는 줄 수준 변경 사항에 대한 완전한 지식이 없었습니다.

이제는 알게 되었습니다! 글을 쓰기 시작하기 전에, 줄 단위 보기에서 잠시 물러나 병합 요청을 다시 넓게 생각해보세요. 이제 병합 요청이 무엇을 하려는지, 그리고 어떻게 하고 있는지 알고 있습니다.

병합 요청의 변경 사항이 의도된 범위와 일치하나요? 그렇지 않다면, 작업을 단순화하거나 여러 병합 요청으로 나누어야 할지 스스로에게 물어보세요. 자신의 지식의 범위와 한계를 솔직하게 인식하세요.
코드 냄새를 감지하나요? 보이는 것이 완전한 버그는 아니지만, 향후 품질, 유지 관리성 또는 보안 문제로 이어질 가능성이 있다면 주의를 기울이세요. 변경 사항이 불안정하거나 이해하기 어렵거나 잘못되었다고 느끼면 본능을 믿으세요. 코드는 기술적으로 올바를 수 있지만, 미래에 문제를 일으킬 수 있는 약점을 포함하고 있을 수 있습니다.

가장 좋고 도움이 되는 코드 리뷰는 줄 단위 수정에만 집중하지 않습니다.

그들은 또한 유지 관리성 및 기술 부채와 같은 장기적인 문제를 고려합니다.

리뷰 마무리하기

피드백을 줄 시간입니다!

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

리뷰 댓글 작성하기

리뷰 시작하기 기능을 사용하면 보류 중인 댓글에 생각을 정리할 수 있습니다. 이러한 댓글은 리뷰를 제출할 때까지 다른 사람에게 보이지 않습니다. 이렇게 하면 수신자에게 메시지가 과부하되지 않고, 게시하기 전에 자신의 말을 다시 확인하고 변경할 기회를 줍니다.

건설적이고 친절하게 말하는 것을 잊지 마세요. 전통적인 댓글의 구조는 사려 깊고 건설적인 댓글을 작성하는 데 도움이 될 수 있습니다.

먼저, 특정 줄이나 파일에 첨부할 댓글을 작성하세요:

변경 사항 탭을 선택합니다.
질문하고 싶거나 피드백을 제공하고 싶은 줄을 찾으면, 이 줄에 댓글 추가 ()를 선택합니다. 이는 diff 줄을 확장하고 댓글 박스를 표시합니다.
또한 여러 줄 선택 또는 전체 파일을 선택하여 댓글을 달 수 있습니다:
텍스트 영역에서 첫 번째 댓글을 작성합니다. 리뷰가 끝날 때까지 댓글을 비공개로 유지하려면, 댓글 아래의 리뷰 시작하기를 선택합니다.
수정이 당신에게 작성하기 쉬운 경우, 또는 저자에게 더 나은 접근 방식을 보여주고 싶다면, 제안 제공을 합니다. 코드 변경이 제안 형식에 비해 너무 크거나 복잡한 경우, 변경 요청 댓글을 남깁니다.
파일과 개별 코드 줄에 계속 댓글을 달아주세요. 각 댓글 이후에 리뷰에 추가를 선택합니다.

작업하면서 빠른 작업, 예를 들어 /label 또는 /assign_reviewer 같은 것을 리뷰 댓글에 사용할 수 있습니다. 보류 중인 댓글은 요청한 작업을 보여주지만, 리뷰를 제출할 때까지 작업은 수행되지 않습니다. (나중에 /submit_review 빠른 작업으로도 리뷰를 제출할 수 있습니다!)

리뷰 요약하기

파일 및 줄별 피드백을 추가한 후, 이제 리뷰를 요약할 준비가 되었습니다. 마지막으로 넓은 시각으로 생각할 시간입니다.

병합 요청의 개요 페이지로 돌아갑니다.
보류 중인 댓글을 스캔합니다. 댓글은 유용하고, 사려 깊으며, 친절해야 하며 - 가장 중요하게는 - 실행 가능해야 합니다.

저자가 발견한 문제를 해결하기 위한 명확한 다음 단계를 제공했습니까?
톤을 고려합니다. 가르치고 있나요, 논쟁하고 있나요, 아니면 토론하고 있나요? 댓글이 목표를 달성하고 있나요? 저자라면 다음에 무엇을 해야 할지 알 수 있을까요? 좋은 행동을 강화하고, 나쁜 행동에서 저자를 밀어내세요.
댓글이 여전히 의미가 있습니까? 큰 병합 요청에서는 일부 댓글이 더 이상 유용하지 않거나 그 동안 당신이 가졌던 질문이 답변되었을 수 있습니다.
일반화된 피드백을 위한 스레드 시작하기. 관련 없는 항목이 같은 댓글에 함께 묶이지 않도록 하여, 스레드가 해결될 때 답변되지 않은 피드백이 숨겨지지 않도록 하세요. 몇 가지 가능한 주제:
- 큰 기능을 더 작은 단일 목적의 함수로 쪼개기.
- 의미 있는 변수 이름 사용하기.
- 복잡한 코드를 설명하기 위해 더 많은 주석 추가하기.
- 엣지 케이스와 오류 확인하기.
요약 댓글을 위한 새로운 스레드 시작하기. 저자가 작업 목록에서 작업할 수 있도록 사용자 이름을 언급하는 것을 잊지 마세요. 명확하게 다음을 상태로 적으세요:
- 전반적인 발견 사항은 무엇인가요?
- 리뷰를 마쳤나요, 아니면 더 작업이 완료된 후 이 병합 요청을 다시 보고 싶으신가요?
리뷰 제출 (또는 /submit_review 빠른 작업을 사용)하여 리뷰의 모든 댓글을 게시합니다.

리뷰를 제출하면 해당 리뷰 댓글에 포함된 모든 빠른 작업도 실행됩니다.
- 변경 사항이 괜찮다면 승인을 선택합니다.
- 변경 사항이 더 작업이 필요하면 변경 요청을 선택합니다.

병합 요청을 승인하면, 리뷰어 목록에 표시된 경우, 당신의 이름 옆에 초록색 체크 표시가 나타납니다.

정리 작업 수행

피드백을 제공한 후, 정리하세요.

모든 보류 중인 댓글이 제출되었는지 확인하세요.
라벨과 마일스톤을 업데이트하세요.
승인 요구 사항을 확인하세요.
- 병합 요청의 각 유형의 작업(백엔드, 프론트엔드, 문서)이 적절한 사람이 검토했나요?
- 더 많은 검토가 필요한 경우, 다음 검토자의 사용자 이름을 언급하고 그들을 검토자로 추가하세요.
병합 위젯을 확인하세요.
- 해결할 수 있는 차단 요소를 처리하고, 해결할 수 없는 차단 요소에 대해 다른 사용자를 지정하세요.
- 리뷰를 위해 필요한 코드 소유자를 추가하세요.
이 병합 요청은 병합할 준비가 되었나요? 병합 요청이 완전히 검토되고 승인되었다면, 유지 관리자가 병합할 수 있도록 지정하세요!