끌어오기 요청을 제출하는 방법

콘텐츠를 변경하려면 포크에서 생성한 후 끌어오기 요청(PR)을 제출하세요. 병합되기 전에 끌어오기 요청은 반드시 검토를 받아야 합니다. 최상의 결과를 보려면 끌어오기 요청을 제출하기 전에 편집 검사 목록을 검토합니다.

git 브랜치 사용

PowerShell-Docs의 기본 분기는 main 분기입니다. 작업 브랜치에서 변경한 내용은 게시하기 전에 먼저 main 브랜치에 병합됩니다. main 브랜치는 매주 평일 태평양 시간 기준 오후 3시에 live 브랜치에 병합됩니다. live 브랜치에는 learn.microsoft.com에 게시되는 콘텐츠가 포함됩니다.

변경 내용을 시작하기 전에 PowerShell-Docs 리포지토리의 로컬 복사본에 작업 분기를 만듭니다. 로컬로 작업하는 경우 작업 분기를 만들기 전에 로컬 리포지토리를 동기화해야 합니다. 분기의 up-to-date 복사본에서 작업 분기를 main 만들어야 합니다.

모든 끌어오기 요청은 브랜치를 main 대상으로 해야 합니다. live 브랜치에 변경사항을 제출하지 마세요. main 브랜치에 있는 변경사항이 live에 병합되어 live에 있는 변경사항을 덮어씁니다.

모든 사용자에 대해 끌어오기 요청 프로세스가 더 잘 작동하게 만들기

PR을 더 간단하고 집중하게 만들수록 더 빠르게 검토하고 병합할 수 있습니다.

많은 수의 파일을 업데이트하거나 관련 없는 변경 내용을 포함하는 끌어오기 요청을 방지합니다.

관련 없는 변경 내용이 포함된 PR을 만들지 않습니다. 새 아티클 또는 주요 재작성에서 기존 아티클에 대한 부 업데이트를 구분합니다. 별도의 작업 분기에서 이러한 변경 내용을 작업합니다.

대량 변경은 많은 수의 변경된 파일이 있는 PR을 만듭니다. PR을 최대 50개 변경된 파일로 제한합니다. 대규모 PR은 검토하기 어렵고 오류를 포함하기 쉽습니다.

파일 이름 바꾸기 또는 삭제

파일 이름을 바꾸거나 삭제할 때 PR과 관련된 문제가 있어야 합니다. 이 문제는 파일의 이름을 바꾸거나 삭제해야 하는 필요성에 대해 논의해야 합니다.

파일 이름 바꾸기 및 삭제와 콘텐츠 추가 또는 변경 내용을 혼합하지 마세요. 이름을 바꾸거나 삭제하는 모든 파일을 적절한 리디렉션 파일에 추가해야 합니다. 가능하면 TOC 파일을 포함하여 이름이 변경되거나 삭제된 콘텐츠에 연결되는 파일을 업데이트합니다.

리포지토리 구성 파일 편집 방지

리포지토리 구성 파일을 수정하지 마세요. 가능한 경우 변경 내용을 Markdown 콘텐츠 파일 및 콘텐츠에 필요한 지원 이미지 파일로 제한합니다.

리포지토리 구성 파일을 잘못 수정하면 빌드가 중단되거나 취약성 또는 접근성 문제가 발생하거나 조직 표준을 위반할 수 있습니다. 리포지토리 구성 파일은 다음 패턴 중 하나 이상과 일치하는 파일입니다.

• *.yml
• .github/**
• .localization-config
• .openpublishing*
• LICENSE*
• reference/docfx.json
• reference/mapping/**
• tests/**
• ThirdPartyNotices
• tools/**

보안 및 보안을 위해 이러한 파일을 변경하지 마세요. 이러한 파일 중 하나를 변경해야 한다고 생각되면 문제를 제출합니다. 유지 관리자가 문제를 심사한 후 적절한 변경 내용을 만듭니다.

PR 템플릿 사용

PR을 만들면 템플릿이 PR 본문에 자동으로 삽입됩니다. 다음과 같습니다.

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

"PR 요약" 섹션에서 변경 내용에 대한 간단한 요약을 작성하고 관련 문제를 문제 번호(예: 문제 번호)로 #1234나열합니다. PR가 문제를 해결하는 경우, PR이 병합될 때 문제가 자동으로 종료되도록 GitHub의 자동 종료 기능을 사용하세요.

"PR 검사 목록" 섹션의 항목을 검토하고 각 항목을 완료할 때 체크합니다. 지침에 따라 팀이 PR을 승인할 각 항목을 확인해야 합니다.

PR이 진행 중인 작업인 경우 초안 모드 로 설정하거나 PR 제목에 접두사를 추가 WIP합니다.

기대에 대한 의견

PR을 제출하면 봇이 PR에 주석을 추가합니다. 주석은 리소스를 제공하고 나머지 프로세스에 대한 기대치를 설정합니다. 이 주석을 주기적으로 업데이트할 수 있으므로 첫 번째 기여가 아니더라도 항상 주석을 검토하세요.

Docs PR 유효성 검사 서비스

Docs PR 유효성 검사 서비스는 변경 내용에 대한 유효성 검사 규칙을 실행하는 GitHub 앱입니다. 유효성 검사 서비스에서 보고한 오류 또는 경고를 수정해야 합니다.

다음 단계에서는 유효성 검사 동작을 간략하게 설명합니다.

1. PR을 제출합니다.

2. 리포지토리에서 활성화된 "검사"의 상태를 나타내는 GitHub 주석에서 이 예제에는 "유효성 검사 커밋" 및 "OpenPublishing.Build"라는 두 가지 검사가 활성화되어 있습니다.

   

   커밋 유효성 검사가 실패하더라도 빌드가 성공할 수 있습니다.

3. 자세한 내용을 보려면 세부 정보를 선택합니다. 세부 정보 페이지에는 실패한 모든 유효성 검사와 문제 해결 방법에 대한 정보가 표시됩니다.

4. 유효성 검사가 성공하면 PR에 다음 주석이 추가됩니다.

   

비고

외부 참가자(Microsoft 직원이 아님)인 경우 자세한 빌드 보고서 또는 미리 보기 링크에 액세스할 수 없습니다.

PR을 검토할 때 변경하거나 유효성 검사 경고 메시지를 수정하라는 메시지가 표시될 수 있습니다. PowerShell-Docs 팀은 유효성 검사 오류 및 편집 요구 사항을 이해하는 데 도움이 될 수 있습니다.

GitHub Actions (GitHub 액션)

변경 내용에 대해 여러 다른 GitHub Actions를 실행하여 사용자와 검토자에게 컨텍스트의 유효성을 검사하고 제공합니다.

검사 목록 확인

PR이 초안 모드 가 아니고 접두사 WIP로 지정되지 않은 경우 GitHub 작업은 PR을 검사하여 PR 템플릿의 검사 목록에 있는 모든 항목을 선택했는지 확인합니다. 검사 목록을 완료할 때까지 유지 관리자가 PR을 검토하거나 병합하지 않습니다. 검사 목록 항목은 필수입니다.

권한 부여 확인

PR이 live 브랜치를 대상으로 하거나 리포지토리 구성 파일을 수정하는 경우, GitHub 액션이 권한을 확인하여 그 변경 사항 제출에 대한 승인이 있는지 확인합니다.

리포지토리 관리자만 분기를 대상으로 하거나 live 리포지토리 구성 파일을 수정할 권한이 있습니다.

버전이 지정된 콘텐츠 변경 보고

PR이 버전이 지정된 콘텐츠를 추가, 제거 또는 수정하는 경우 GitHub Action은 변경 내용을 분석하고 버전이 지정된 콘텐츠의 변경 유형을 요약하는 보고서를 작성합니다.

이 보고서는 이 PR에서 업데이트해야 하는 다른 버전의 파일이 있는지 표시할 수 있습니다.

PR용 버전 콘텐츠 리포트를 찾으려면 다음 단계를 따르세요.

1. PR 페이지에서 "검사" 탭을 선택합니다.
2. 작업 목록에서 "보고" 작업을 선택합니다.
3. "..." 선택 단추가 오른쪽 위에 있습니다.
4. "작업 요약 보기"를 선택합니다.

다음 단계

PowerShell-Docs 스타일 가이드

추가 리소스

끌어오기 요청 관리하는 방법