이 섹션에서는 끌어오기 요청을 통해 커뮤니티가 Django에 코드를 제공하는 방법을 설명합니다. mergers `를 처리하는 방법에 관심이 있다면 :doc:../committing-code`을 참조하십시오.
\n아래에서는 Trac ticket #xxxxx에 대한 변경 사항이 포함된 GitHub 풀 요청을 생성하는 방법을 보여드리겠습니다. 완전히 준비된 풀 요청을 작성하면 검토자의 작업이 더 쉬워집니다. 즉, 작업이 Django에 병합될 가능성이 높습니다.
\n기존 패치를 Trac에 업로드할 수도 있지만 리뷰에는 덜 실용적입니다.
\nDjango는 소스 제어에 `Git`을 사용합니다. <https://git-scm.com/download>_ Git을 다운로드 할 수 있지만 운영 체제의 패키지 관리자를 사용하여 설치하는 것이 더 쉽습니다.
\nDjango’s Git repository is hosted on GitHub, and it is recommended\nthat you also work using GitHub.
\nGit을 설치한 후 가장 먼저 해야 할 일은 이름과 이메일을 설정하는 것입니다.
\n$ git config --global user.name "Your Real Name"\n$ git config --global user.email "you@email.com"\n‘user.name’은 GitHub 닉이 아닌 실제 이름이어야 합니다. GitHub은 “user.email” 필드에서 사용하는 전자 메일을 알고 있어야 합니다. 이 전자 메일은 커밋을 GitHub 계정과 연결하는 데 사용됩니다.
\n“GitHub_nick”이라는 닉네임과 “forked Django’s repository <https://github.com/django/django/fork>_”로 GitHub 계정을 생성하면 포크의 로컬 복사본을 생성합니다.
\ngit clone https://github.com/GitHub_nick/django.git\n그러면 GitHub 리포지토리의 복제본을 포함하는 새 디렉토리 “jango”가 생성됩니다. 이 페이지의 나머지 git 명령은 복제된 디렉토리 내에서 실행해야 하므로 지금 전환하십시오.
\ncd django\nGitHub 저장소는 Git에서 “origin”이라고 합니다.
\n또한 ‘’django/django’’를 “업스트림” 리모트로 설정해야 합니다(즉, 참조 Django 저장소가 포크의 소스였다고 git에게 말하세요).
\ngit remote add upstream https://github.com/django/django.git\ngit fetch upstream\n다음과 같이 다른 원격도 비슷하게 추가할 수 있습니다.
\ngit remote add akaariai https://github.com/akaariai/django.git\n티켓 작업을 할 때 작업에 대한 새 분기를 만들고 “upstream/main”을 기반으로 작업합니다.
\ngit checkout -b ticket_xxxxx upstream/main\n-b 플래그는 로컬로 새 분기를 만듭니다. 작은 일에도 불구하고 새로운 지점을 만드는 것을 주저하지 마십시오. 그것이 바로 그 목적입니다.
\n대신 1.4 분기에서 수정 작업을 수행한다면 다음과 같은 작업을 수행할 수 있습니다.
\ngit checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x\n작업이 ticket_xxxxxx 분기에서 진행된다고 가정합니다. 몇 가지 내용을 변경하고 커밋합니다.
\ngit commit\n커밋 메시지를 작성할 때 :ref:”커밋 메시지 지침”을 따라 병합 작업을 용이하게 합니다. 만약 영어가 불편하다면, 최소한 그 커밋이 무엇을 하는지 정확하게 설명하도록 노력하세요.
\n지점에서 추가 작업을 수행해야 하는 경우 필요한 만큼 자주 커밋하십시오.
\ngit commit -m 'Added two more tests for edge cases'\n다음을 실행하여 GitHub에 작품을 게시할 수 있습니다.
\ngit push origin ticket_xxxxx\nGitHub 페이지로 이동하면 새 분기가 생성되었음을 알 수 있습니다.
\nTrac 티켓을 작업하는 경우 GitHub repo의 branch ticket_xxxxxx에서 작업을 수행할 수 있음을 티켓에 언급해야 합니다. 분기에 대한 링크를 포함합니다.
\n위의 분기를 Git parance에서 “토픽 분기”라고 합니다. 예를 들어 “gitrebase”를 사용하여 이 지점의 기록을 자유롭게 다시 작성할 수 있습니다. 커밋을 편집할 때 복제본이 손상되기 때문에 다른 사용자는 이러한 분기에 기반하여 작업을 수행해서는 안 됩니다.
\n“public branches”도 있습니다. 이것들은 다른 사람들이 포크해야 하는 지점들이기 때문에, 이 지점들의 역사는 절대 바뀌어서는 안 됩니다. 공용 분기의 좋은 예로는 django/django 저장소에 있는 ``main``와 ``stable/A.B.x` 분기가 있습니다.
작업을 Django로 풀 할 준비가 되었다고 생각되면 GitHub에서 풀 요청을 작성해야 합니다. 좋은 풀 요청은 다음을 의미합니다.
\ncoding style 1,에 따라 각각 하나의 논리적 변경으로 커밋합니다.
각 커밋에 대한 올바른 형식의 메시지: 요약 줄과 72자로 요약된 단락 - 자세한 내용은 :ref:”커밋 지침”을 참조하십시오.
설명서 및 테스트(필요한 경우)는 문서 변경을 제외하고 실제로 항상 테스트가 필요합니다.
테스트 제품군을 통과해야 하며 설명서는 경고 없이 작성되어야 합니다.
\n풀 요청을 만든 후에는 관련 Trac 티켓에 사용자가 수행한 작업을 설명하는 설명을 추가해야 합니다. 특히 “ SQLite 및 MySQL에서 통과하는 모든 테스트”와 같은 테스트를 실행한 환경에 주목해야 합니다.
\nGitHub의 Pull 요청에는 열린 상태와 닫힌 상태 두 가지 상태만 있습니다. 풀 요청을 처리할 병합에는 병합 또는 닫기의 두 가지 옵션만 있습니다. 이러한 이유로 코드가 병합될 준비가 되거나 병합이 자체적으로 완료될 정도로 충분히 가까워질 때까지 풀 요청을 하는 것은 유용하지 않습니다.
\n위의 예에서는 “Fixed ticket_xxxx” 커밋과 “Test 2개 추가” 커밋이라는 두 가지 커밋을 만들었습니다.
\n작업 프로세스의 전체 이력을 리포지토리에 저장하지 않습니다. “테스트 두 개 추가”라는 약속은 도움이 되지 않는 잡음이 될 것입니다. 대신, 우리는 당신의 모든 일을 포함하는 하나의 약속만을 원합니다.
\n분기 기록을 다시 작성하려면 대화형 rebase를 사용하여 커밋을 하나로 스쿼시할 수 있습니다.
\ngit rebase -i HEAD~2\n위의 HEAD~2는 최근 두 가지 커밋의 약자입니다. 위의 명령어는 “pick”이라는 단어 앞에 있는 두 개의 커밋을 보여주는 편집기를 엽니다.
\n대신 두 번째 줄의 “선택”을 “파쇄”로 변경합니다. 이렇게 하면 첫 번째 커밋이 유지되고 두 번째 커밋이 첫 번째 커밋으로 스쿼시됩니다. 편집기를 저장한 후 종료합니다. 두 번째 편집기 창이 열리면 커밋 메시지에 대한 단어를 바꿀 수 있습니다. 이제 커밋 메시지에 두 단계가 모두 포함됩니다.
\nrebase에서 “edit” 옵션을 사용할 수도 있습니다. 이 방법으로 단일 커밋을 변경할 수 있습니다. 예를 들어, 문서 문자열의 오타를 수정합니다.
\ngit rebase -i HEAD~3\n# Choose edit, pick, pick for the commits\n# Now you are able to rework the commit (use git add normally to add changes)\n# When finished, commit work with "--amend" and continue\ngit commit --amend\n# Reword the commit message if needed\ngit rebase --continue\n# The second and third commits should be applied.\n예를 들어 리뷰를 고려하기 위해 사소한 변경을 하는 경우처럼 주제 분기가 GitHub에 이미 게시되어 있는 경우 변경 사항을 강제로 푸시해야 합니다.
\ngit push -f origin ticket_xxxxx\n이렇게 하면 ticket_xxxxx의 기록이 다시 작성됩니다. GitHub에서 작업 전후에 커밋 해시를 확인하면 커밋 해시가 더 이상 일치하지 않음을 알 수 있습니다. 분기는 주제 분기로, 누구도 작업에 기반을 두어서는 안 되기 때문에 이는 허용됩니다.
\n업스트림(django/django)이 바뀌면 작업을 다시 기본으로 해야 합니다. 이렇게 하려면 다음을 사용합니다.
git fetch upstream\ngit rebase\n이 작업은 “upstream/main”을 사용하는 예에서와 같이 사용자가 분기한 분기를 사용하여 자동으로 리베이스화됩니다.
\nrebase 명령은 일시적으로 모든 로컬 커밋을 제거하고 업스트림 커밋을 적용한 다음 로컬 커밋을 작업에 다시 적용합니다.
\n병합 충돌이 있는 경우 이를 해결하고 “gitrebase –continue”를 사용해야 합니다. 언제든지 “git rebase –abort”를 사용하여 원래 상태로 돌아갈 수 있습니다.
\n업스트림을 *머지*하지 않고 업스트림에 *리베이스*를 지정하려고 합니다.
\n그 이유는 기본 재배치함으로써 커밋은 항상 업스트림의 작업과 *혼합*되는 것이 아니라 *업스트림의 작업에 *상위*되기 때문입니다. 이렇게 하면 분기에 해당 주제와 관련된 커밋만 포함되므로 쉽게 스퀴싱할 수 있습니다.
\n검토자가 요청한 변경 사항 없이 사소한 양의 코드를 코어로 가져오는 것은 드문 일입니다. 이 경우 변경 사항을 작업에 대한 하나의 증분 커밋으로 추가하는 것이 좋습니다. 이렇게 하면 검토자는 사용자가 변경한 내용을 쉽게 확인할 수 있습니다.
\n이 경우 검토자가 요구하는 내용을 변경하십시오. 필요한 만큼 자주 커밋합니다. 변경 내용을 게시하기 전에 작업 내용을 다시 정의하십시오. 두 개의 커밋을 추가한 경우 다음을 실행합니다.
\ngit rebase -i HEAD~2\n두 번째 커밋을 첫 번째 커밋으로 밀어 넣습니다. 다음 행에 커밋 메시지를 작성합니다.
\nMade changes asked in review by <reviewer>\n\n- Fixed whitespace errors in foobar\n- Reworded the docstring of bar()\n마지막으로 GitHub 저장소로 작업을 다시 푸쉬하십시오. 기본 재배치 중에 공개 커밋을 건드리지 않았으므로, 다음을 강제로 푸시할 필요가 없습니다.
\ngit push origin ticket_xxxxx\n이제 풀 요청에도 새 커밋이 포함됩니다.
\n병합은 코드를 커밋할 때 검토 커밋을 이전 커밋으로 압축할 가능성이 높습니다.
\n개발자가 장고에 기여할 수 있는 방법 중 하나는 패치를 검토하는 것입니다. 이러한 패치는 일반적으로 GitHub에서 풀 요청으로 존재하며 로컬 저장소에 쉽게 통합할 수 있습니다.
\ngit checkout -b pull_xxxxx upstream/main\ncurl https://github.com/django/django/pull/xxxxx.patch | git am\n이렇게 하면 새 분기가 생성된 다음 꺼내기 요청의 변경 사항이 해당 분기에 적용됩니다. 이때 테스트를 실행하거나 패치 품질을 조사하는 데 필요한 다른 작업을 수행할 수 있습니다.
\n풀 요청 작업에 대한 자세한 내용은 :ref:’합병 지침을 참조하십시오.
\n가능하면 GitHub에서 작업하십시오.
GitHub 브랜치에 링크하여 Trac 티켓에 대한 작업을 공지합니다.
준비가 되면 풀 요청을 하세요.
가능한 한 풀 요청을 하세요.
작업을 수정할 때는 “git rebase -i”를 사용하여 커밋을 스쿼시합니다.
업스트림이 변경되면 “git fetch upstream; git rebase”를 수행합니다.