신속한 코드 검토를 위한 병합 요청의 3가지 필수 사항

코드 협업의 중요한 부분 중 하나는 병합 요청(MR)입니다.

여기에서 리포지토리의 다른 구성원에게 코드 솔루션에 대해 알릴 수 있습니다.

병합 요청에 대한 검토가 가능한 한 신속하게 이루어지도록 합시다.

당신뿐만 아니라 리뷰어를 위해

1. 제목



제목은 좋은 MR에게 매우 중요합니다. 좋은 제목은 MR이 무엇인지 설명해야 합니다.

웹페이지의 SEO 제목으로 생각하십시오.

오해의 소지가 있는 경우 검토자는 핵심 아이디어 또는 병합 요청에 대한 이유를 얻기 위해 열심히 노력해야 합니다.

예를 들어:

나쁜: Refactoring Components
좋은: ABC-123: Refactor Login Flow for Better Error Handling
그것은 나에게 말한다 :
  • 이 변경에 대한 티켓이 있습니다.
  • UI의 어떤 부분이 일부 변경되어야 하는지
  • 변경 사유



  • 2. 간략한 설명



    물론 제목이 모든 것을 가질 수는 없습니다.

    그래서 설명이 있습니다.

    제목을 달성하기 위해 수행한 주요 변경 사항에 대해 간략하게 설명해야 합니다.

    위의 MR 제목에 대해 다음과 같은 설명이 적절할 수 있습니다. ""

    - Removed unnecessary Props
    - Adopted composition of Component and reduced Prop Drilling
    - UI Error reporting is unified for a form via the `useErrors` hook
    - Inputs are now logic-less allowing better testing 
    


    이제 위의 설명을 통해 파일 변경 사항을 예상하고 특정 영역의 코드에 더 많은 관심을 기울일 것입니다.


    3. 관련 티켓/발권



    일부 티켓으로 코드에 변경 사항이 도입되어야 합니다.

    이 티켓은 버그, 기능/스토리, 작업 등이 될 수 있습니다.

    티켓의 존재는 리포지토리 외부에서 문서화 및 변경 사유를 허용+유지합니다.

    코드 외부의 것들과 함께 코드가 아닌 참가자들과 협업할 수 있습니다.

    어떤 경우에는 티켓과 MR이 같은 시스템에 있습니다.

    예를 들어 Issues from GH는 PR 티켓입니다.


    결론



    위의 점들이 리뷰어가 리뷰할 내용을 준비할 수 있게 해준다고 생각합니다.

    What would you need as a Reviewer as a must-have?



    댓글 💬 또는 Twitter 및/또는
    이 기사가 도움이 되었다면 다른 사람들과 공유해 주세요 🗣
    블로그를 구독하면 받은 편지함으로 바로 새 게시물을 받을 수 있습니다.

    좋은 웹페이지 즐겨찾기