이 섹션에서는 끌어오기 요청을 통해 커뮤니티가 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.
\nAfter installing Git, the first thing you should do is set up your name and\nemail:
\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 계정과 연결하는 데 사용됩니다.
\nWhen you have created your GitHub account, with the nick “GitHub_nick”, and\nforked Django’s repository,\ncreate a local copy of your fork:
\ngit clone https://github.com/GitHub_nick/django.git\nThis will create a new directory “django”, containing a clone of your GitHub\nrepository. The rest of the git commands on this page need to be run within the\ncloned directory, so switch to it now:
\ncd django\nGitHub 저장소는 Git에서 “origin”이라고 합니다.
\nYou should also set up django/django as an “upstream” remote (that is, tell\ngit that the reference Django repository was the source of your fork of it):
git remote add upstream https://github.com/django/django.git\ngit fetch upstream\nYou can add other remotes similarly, for example:
\ngit remote add akaariai https://github.com/akaariai/django.git\nWhen working on a ticket, create a new branch for the work, and base that work\non upstream/main:
git checkout -b ticket_xxxxx upstream/main\n-b 플래그는 로컬로 새 분기를 만듭니다. 작은 일에도 불구하고 새로운 지점을 만드는 것을 주저하지 마십시오. 그것이 바로 그 목적입니다.
\nIf instead you were working for a fix on the 1.4 branch, you would do:
\ngit checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x\nAssume the work is carried on the ticket_xxxxx branch. Make some changes and\ncommit them:
\ngit commit\n커밋 메시지를 작성할 때 :ref:”커밋 메시지 지침”을 따라 병합 작업을 용이하게 합니다. 만약 영어가 불편하다면, 최소한 그 커밋이 무엇을 하는지 정확하게 설명하도록 노력하세요.
\nIf you need to do additional work on your branch, commit as often as\nnecessary:
\ngit commit -m 'Added two more tests for edge cases'\nYou can publish your work on GitHub by running:
\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작업 프로세스의 전체 이력을 리포지토리에 저장하지 않습니다. “테스트 두 개 추가”라는 약속은 도움이 되지 않는 잡음이 될 것입니다. 대신, 우리는 당신의 모든 일을 포함하는 하나의 약속만을 원합니다.
\nTo rework the history of your branch you can squash the commits into one by\nusing interactive rebase:
\ngit rebase -i HEAD~2\n위의 HEAD~2는 최근 두 가지 커밋의 약자입니다. 위의 명령어는 “pick”이라는 단어 앞에 있는 두 개의 커밋을 보여주는 편집기를 엽니다.
\n대신 두 번째 줄의 “선택”을 “파쇄”로 변경합니다. 이렇게 하면 첫 번째 커밋이 유지되고 두 번째 커밋이 첫 번째 커밋으로 스쿼시됩니다. 편집기를 저장한 후 종료합니다. 두 번째 편집기 창이 열리면 커밋 메시지에 대한 단어를 바꿀 수 있습니다. 이제 커밋 메시지에 두 단계가 모두 포함됩니다.
\nYou can also use the “edit” option in rebase. This way you can change a single\ncommit, for example to fix a typo in a docstring:
\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.\nIf your topic branch is already published at GitHub, for example if you’re\nmaking minor changes to take into account a review, you will need to force-push\nthe changes:
\ngit push -f origin ticket_xxxxx\n이렇게 하면 ticket_xxxxx의 기록이 다시 작성됩니다. GitHub에서 작업 전후에 커밋 해시를 확인하면 커밋 해시가 더 이상 일치하지 않음을 알 수 있습니다. 분기는 주제 분기로, 누구도 작업에 기반을 두어서는 안 되기 때문에 이는 허용됩니다.
\nWhen upstream (django/django) has changed, you should rebase your work. To\ndo this, use:
git fetch upstream\ngit rebase upstream/main\n이 작업은 “upstream/main”을 사용하는 예에서와 같이 사용자가 분기한 분기를 사용하여 자동으로 리베이스화됩니다.
\nrebase 명령은 일시적으로 모든 로컬 커밋을 제거하고 업스트림 커밋을 적용한 다음 로컬 커밋을 작업에 다시 적용합니다.
\n병합 충돌이 있는 경우 이를 해결하고 “gitrebase –continue”를 사용해야 합니다. 언제든지 “git rebase –abort”를 사용하여 원래 상태로 돌아갈 수 있습니다.
\n업스트림을 *머지*하지 않고 업스트림에 *리베이스*를 지정하려고 합니다.
\n그 이유는 기본 재배치함으로써 커밋은 항상 업스트림의 작업과 *혼합*되는 것이 아니라 *업스트림의 작업에 *상위*되기 때문입니다. 이렇게 하면 분기에 해당 주제와 관련된 커밋만 포함되므로 쉽게 스퀴싱할 수 있습니다.
\n검토자가 요청한 변경 사항 없이 사소한 양의 코드를 코어로 가져오는 것은 드문 일입니다. 이 경우 변경 사항을 작업에 대한 하나의 증분 커밋으로 추가하는 것이 좋습니다. 이렇게 하면 검토자는 사용자가 변경한 내용을 쉽게 확인할 수 있습니다.
\nIn this case, do the changes required by the reviewer. Commit as often as\nnecessary. Before publishing the changes, rebase your work. If you added two\ncommits, you would run:
\ngit rebase -i HEAD~2\nSquash the second commit into the first. Write a commit message along the lines\nof:
\nMade changes asked in review by <reviewer>\n\n- Fixed whitespace errors in foobar\n- Reworded the docstring of bar()\nFinally, push your work back to your GitHub repository. Since you didn’t touch\nthe public commits during the rebase, you should not need to force-push:
\ngit push origin ticket_xxxxx\n이제 풀 요청에도 새 커밋이 포함됩니다.
\n병합은 코드를 커밋할 때 검토 커밋을 이전 커밋으로 압축할 가능성이 높습니다.
\nOne of the ways that developers can contribute to Django is by reviewing\npatches. Those patches will typically exist as pull requests on GitHub and\ncan be easily integrated into your local repository:
\ngit checkout -b pull_xxxxx upstream/main\ncurl -L 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”를 수행합니다.