풀 리퀘스트 수락하기¶
이 페이지는 코어 팀이 메인 저장소의 풀 리퀘스트를 평가하고 병합하며, 필요한 경우 백포트하는 과정을 단계별로 안내합니다.
풀 리퀘스트 평가하기¶
풀 리퀘스트를 수락하기 전에 그것이 공개 소스 트리에 들어갈 준비가 되었는지 확인해야 합니다. 다음 질문을 스스로 던져 보십시오:
- 이슈 추적기에서 진행 중인 논의가 있습니까?
연결된 이슈를 읽으십시오. 진행 중인 논의가 있다면 풀 리퀘스트를 병합하기 전에 그곳에서 결론을 내야 합니다.
- 풀 리퀘스트가 처음부터 적절한 브랜치를 대상으로 만들어졌습니까?
새 기능을 받는 유일한 브랜치는 개발 중인 브랜치인
main입니다. 풀 리퀘스트는 이슈가 해당 버전과 경우에 따라 그 이전 버전에서만 나타나는 경우에만 버그 수정 브랜치를 대상으로 해야 합니다.
- 변경 사항을 수용할 수 있습니까?
기능이나 버그 수정에 관해 작업 중인 코드를 공유하고 싶다면
WIP접두사가 붙은 풀 리퀘스트를 열거나, issue tracker에 패치를 게시하거나, 저장소의 공개 포크를 만들 수 있습니다.
- 풀 리퀘스트의 검사 결과가 테스트 스위트 통과를 보여 줍니까?
모든 상태 검사가 통과하는지 확인하십시오.
- 풀 리퀘스트가 양호한 상태입니까?
풀 리퀘스트의 수명 주기와 이슈 트리아지 돕기를 확인하여 풀 리퀘스트에 기대되는 사항을 검토하십시오.
- 변경 사항이 타당한 이유 없이 하위 호환성을 깨뜨립니까?
모든 것이 여전히 통과하는지 확인하려면 전체 테스트 스위트를 실행하십시오. 의미론이 변경된다면 일부 사람들의 코드가 깨지게 되므로 타당한 이유가 있어야 합니다. 호환성을 깨뜨릴 만한 가치가 있는지 확신이 서지 않는다면 Core Development Discourse 카테고리에서 문의하십시오.
- 문서를 갱신해야 합니까?
풀 리퀘스트가 하위 호환되지 않는 변경 사항(예를 들어 기능의 폐지 예정 또는 제거)을 도입한다면 풀 리퀘스트를 병합하기 전에 해당 변경 사항이 문서에 반영되었는지 확인하십시오.
- 풀 리퀘스트의 백포트 필요성을 나타내는 적절한 레이블이 추가되었습니까?
풀 리퀘스트를 하나 이상의 유지 보수 브랜치로 백포트해야 한다고 판단되면 코어 개발자가 풀 리퀘스트에
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항목이 필요하지 않습니다.
풀 리퀘스트 병합하기¶
풀 리퀘스트가 준비되면 여러분(코어 팀 구성원)이 병합할 수 있습니다. 다른 사람들이 리뷰에 상당히 관여했다면, 코어 팀 구성원이 이미 풀 리퀘스트를 승인했더라도 그들의 승인을 기다리는 것이 좋을 수 있습니다.
CPython 저장소는 스쿼시만 허용하도록 설정되어 있습니다. 여러분은 풀 리퀘스트를 스쿼시하게 됩니다.
커밋 메시지¶
GitHub는 풀 리퀘스트에 있는 모든 개별 커밋 메시지를 합친 목록을 스쿼시된 커밋 메시지의 기본값으로 사용합니다. 그 메시지들을 그대로 두지 마십시오. 그런 메시지는 너무 장황하고 맥락을 거의 제공하지 않는 경우가 많습니다. 특히 개발자들은 자신의 작업이 결국 스쿼시될 것을 알고 있으므로, 풀 리퀘스트 작업 중에 작성한 중간 커밋 메시지는 유용하지 않습니다.
중요하다고 생각한다면 풀 리퀘스트에 들어간 공동 작업을 요약할 수 있지만, 반드시 그럴 필요는 없습니다. 이력을 자세히 조사할 때는 풀 리퀘스트나 원래 이슈를 여전히 참고할 수 있습니다.
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.