풀 리퀘스트 수락하기¶

이 페이지는 코어 팀이 메인 저장소의 풀 리퀘스트를 평가하고 병합하며 필요한 경우 백포트하기 위한 단계별 안내서입니다.

풀 리퀘스트 평가하기¶

풀 리퀘스트를 수락하기 전에 공개 소스 트리에 포함될 준비가 되었는지 확인해야 합니다. 다음 질문을 스스로에게 해 보십시오:

이슈 추적기에서 논의가 진행 중입니까?
연결된 이슈를 읽으십시오. 논의가 진행 중이라면 풀 리퀘스트를 병합하기 전에 해당 논의가 해결되어야 합니다.
풀 리퀘스트가 처음부터 적절한 브랜치를 대상으로 만들어졌습니까?
새 기능을 받는 유일한 브랜치는 개발 중인 브랜치인 main입니다. 풀 리퀘스트는 이슈가 해당 버전과 일부 이전 버전에만 나타나는 경우에만 버그 수정 브랜치를 대상으로 해야 합니다.
변경 사항을 수용할 수 있습니까?
기능 또는 버그 수정에 관한 작업 중인 코드를 공유하려면 WIP 접두사가 붙은 풀 리퀘스트를 열거나, issue tracker에 패치를 게시하거나, 저장소의 공개 포크를 만들 수 있습니다.
풀 리퀘스트의 검사 결과는 테스트 스위트가 통과함을 보여 줍니까?
모든 상태 검사가 통과하는지 확인하십시오.
풀 리퀘스트가 양호한 상태입니까?
풀 리퀘스트에 요구되는 사항을 검토하려면 풀 리퀘스트의 수명 주기와 이슈 트리아지 돕기를 확인하십시오.
변경 사항이 타당한 이유 없이 하위 호환성을 깨뜨립니까?
모든 것이 여전히 통과하는지 확인하려면 전체 테스트 스위트를 실행하십시오. 의미론이 변경된다면 일부 사용자의 코드가 작동하지 않게 되므로 타당한 이유가 있어야 합니다. 호환성을 깨뜨릴 가치가 있는지 확실하지 않다면 코어 개발 디스코스 카테고리에 질문하십시오.
문서를 업데이트해야 합니까?
풀 리퀘스트가 하위 호환되지 않는 변경 사항(예: 기능의 지원 중단 예정 또는 제거)을 도입한다면 풀 리퀘스트를 병합하기 전에 해당 변경 사항이 문서에 반영되어 있는지 확인하십시오.
풀 리퀘스트에 필요한 백포트를 나타내는 적절한 레이블이 추가되었습니까?
풀 리퀘스트를 하나 이상의 유지보수 브랜치로 백포트해야 한다고 결정되면 코어 개발자는 풀 리퀘스트에 needs backport to X.Y 레이블을 적용할 수 있습니다. 백포트 풀 리퀘스트가 생성되면 원본 풀 리퀘스트에서 needs backport to X.Y 레이블을 제거하십시오. (코어 팀과 Python 트리아지 팀의 구성원만 GitHub 풀 리퀘스트에 레이블을 적용할 수 있습니다).
풀 리퀘스트가 제출자가 CLA에 서명했음을 나타내는 검사를 통과합니까?
변경 사항과 관련된 지식 재산이 존재할 가능성이 전혀 없는 경우(예: 문서의 철자 오류 수정)가 아니라면 기여자가 기여자 라이선스 계약 (CLA)에 서명했는지 확인하십시오. Python 소프트웨어 재단 기여자 라이선스 계약 관리 봇은 작성자가 CLA에 서명했는지 확인하고, 서명하지 않았다면 PR에 답글을 남깁니다. CLA 절차에 관해 추가로 질문하려면 contributors@python.org로 문의하십시오.
What's New in Python과 Misc/NEWS.d/next가 업데이트되었습니까?
변경 사항이 최종 사용자에게 특히 흥미로운 경우(예: 새로운 기능, 상당한 개선 또는 하위 호환성을 깨뜨리는 변경)에는 What's New in Python 문서(Doc/whatsnew/ 안에 있음)에도 항목을 추가해야 합니다. 문서에만 영향을 미치는 변경 사항에는 일반적으로 NEWS 항목이 필요하지 않습니다.

더 보기

NEWS와 Python의 새로운 기능 업데이트

풀 리퀘스트 병합하기¶

풀 리퀘스트가 준비되면 코어 팀 구성원인 여러분이 이를 병합할 수 있습니다. 다른 사람들이 검토에 상당히 관여했다면 코어 팀 구성원이 이미 풀 리퀘스트를 승인했더라도 그들의 승인을 기다리는 것이 좋습니다.

CPython 저장소는 스쿼시만 허용하도록 구성되어 있습니다. 풀 리퀘스트를 스쿼시합니다.

커밋 메시지¶

GitHub는 기본적으로 풀 리퀘스트에 있는 모든 개별 커밋 메시지를 결합한 목록을 스쿼시된 커밋 메시지로 사용합니다. 해당 메시지를 그대로 두지 마십시오. 이러한 메시지는 대개 지나치게 장황하고 맥락을 거의 제공하지 않으며, 특히 개발자는 자신의 작업이 결국 스쿼시될 것임을 알고 있으므로 풀 리퀘스트 작업 중의 중간 커밋 메시지는 중요하지 않습니다.

중요하다고 생각한다면 풀 리퀘스트에 포함된 공동 작업을 요약할 수 있지만 반드시 그럴 필요는 없습니다. 풀 리퀘스트 및/또는 원래 이슈는 과거 이력을 자세히 조사할 때 여전히 사용할 수 있습니다.

Git 사용하기¶

Git 부트캠프와 치트 시트

코어 팀 구성원은 공식 Python 저장소에 변경 사항을 푸시할 수 있으므로 작업 흐름에 주의해야 합니다:

메인 저장소에 새 브랜치를 푸시해서는 안 됩니다. 자체 개발에 사용하는 포크에서는 계속 사용할 수 있습니다. 메인 저장소에 통합하기 전의 유지 관리 작업을 위해 이러한 브랜치를 별도의 공개 저장소에 푸시할 수도 있습니다.
직접 커밋해서는 안 되는 곳은 main 브랜치와 모든 유지 관리 브랜치입니다. 자체 기능 브랜치에 커밋한 다음 풀 리퀘스트를 생성해야 합니다.
작은 변경 사항은 GitHub 웹 UI에서 빠르게 편집할 수 있습니다. 웹 UI를 사용하기로 했다면 GitHub가 여러분의 포크가 아니라 메인 CPython 저장소에 새 브랜치를 생성한다는 점에 유의하십시오. 새로 생성된 이 브랜치가 main 브랜치나 유지 관리 브랜치 중 하나에 병합된 후에는 삭제하십시오. CPython 저장소를 깔끔하게 유지하려면 며칠 이내에 새 브랜치를 제거하십시오.

로컬 클론이 마음에 들지 않을 때 모든 로컬 변경 사항을 커밋한 것까지 되돌릴 수 있도록 메인 저장소의 포크를 유지하십시오.

활성 브랜치 확인하기¶

git branch를 사용하면 브랜치 목록을 볼 수 있습니다. 새 기능을 받는 유일한 브랜치는 개발 중인 브랜치인 main 브랜치입니다. 다른 브랜치에는 버그 수정이나 보안 수정만 적용됩니다. 거의 모든 경우에 수정 사항은 먼저 main에서 만들어진 다음 이전 브랜치로 백포트되어야 합니다.

이전 버전으로 변경 사항 백포트하기¶

이 섹션은 병합된 변경 사항 백포트하기로 이동했습니다.

병합된 풀 리퀘스트 되돌리기¶

병합된 풀 리퀘스트를 되돌리려면 풀 리퀘스트 하단의 Revert 버튼을 누르십시오. 그러면 커밋을 되돌릴 새 풀 리퀘스트를 생성하는 페이지가 열립니다. 또한 기본 CPython 저장소에 새 브랜치가 생성됩니다. 풀 리퀘스트가 병합되면 해당 브랜치를 삭제하십시오.

다른 사람들이 커밋을 되돌린 이유를 이해할 수 있도록 항상 그 이유를 포함하십시오. 해당 이유는 커밋 메시지의 일부로 포함해야 합니다. 다음은 예시입니다.:

Revert gh-NNNN: Fix Spam Module (GH-111)

Reverts python/cpython#111.
Reason: This commit broke the buildbot.