{"title":"Git 및 GitHub와 함께 작업","version":"6.1","locale":"ko","docname":"internals/contributing/writing-code/working-with-git","url":"/ko/6.1/internals/contributing/writing-code/working-with-git/","canonical":"https://djangodocs.dev/ko/6.1/internals/contributing/writing-code/working-with-git/","summary":"이 섹션에서는 pull request를 통해 커뮤니티가 Django에 코드를 기여하는 방법을 설명합니다. :ref: ` mergers `가 이를 어떻게 처리하는지에 관심이 있다면 :ref: ` handling-pull-requests`를 참고하세요. 아래에서는 Trac…","html":"

Git 및 GitHub와 함께 작업Link to this heading#

\n

이 섹션에서는 pull request를 통해 커뮤니티가 Django에 코드를 기여하는 방법을 설명합니다. :ref:`mergers <mergers-team>`가 이를 어떻게 처리하는지에 관심이 있다면 :ref:`handling-pull-requests`를 참고하세요.

\n

아래에서는 Trac ticket #xxxxx에 대한 변경 사항이 포함된 GitHub 풀 요청을 생성하는 방법을 보여드리겠습니다. 완전히 준비된 풀 요청을 작성하면 검토자의 작업이 더 쉬워집니다. 즉, 작업이 Django에 병합될 가능성이 높습니다.

\n

기존 패치를 Trac에 업로드할 수도 있지만 리뷰에는 덜 실용적입니다.

\n
\n

GIT 설치Link to this heading#

\n

Django는 소스 제어에 `Git`을 사용합니다. <https://git-scm.com/download>_ Git을 다운로드 할 수 있지만 운영 체제의 패키지 관리자를 사용하여 설치하는 것이 더 쉽습니다.

\n

Django’s Git repository is hosted on GitHub, and it is recommended\nthat you also work using GitHub.

\n

Git을 설치한 후 가장 먼저 해야 할 일은 이름과 이메일을 설정하는 것입니다.

\n
Shell
$ git config --global user.name "Your Real Name"\n$ git config --global user.email "you@email.com"\n
\n

‘user.name’은 GitHub 닉이 아닌 실제 이름이어야 합니다. GitHub은 “user.email” 필드에서 사용하는 전자 메일을 알고 있어야 합니다. 이 전자 메일은 커밋을 GitHub 계정과 연결하는 데 사용됩니다.

\n
\n
\n

로컬 리포지토리를 설정하는 중입니다.Link to this heading#

\n

“GitHub_nick”이라는 닉네임으로 GitHub 계정을 생성하고 Django 저장소를 포크한 다음, 포크의 로컬 복사본을 생성하세요.

\n
Shell
git clone https://github.com/GitHub_nick/django.git\n
\n

그러면 GitHub 저장소의 복제본을 포함한 새 디렉토리 “django”가 생성됩니다. 이 페이지의 나머지 Git 명령은 복제된 디렉토리에서 실행해야 하므로, 지금 해당 디렉토리로 이동하세요.

\n
Shell
cd django\n
\n

GitHub 저장소는 Git에서 “origin”이라고 합니다.

\n

또한 ``django/django``를 “upstream” 리모트로 설정해야 합니다(즉, 원본 Django 저장소를 포크의 기준 저장소로 git에 지정하는 것입니다).

\n
Shell
git remote add upstream https://github.com/django/django.git\ngit fetch upstream\n
\n

다음과 같이 다른 원격 저장소도 추가할 수 있습니다.

\n
Shell
git remote add akaariai https://github.com/akaariai/django.git\n
\n
\n
\n

티켓 작업을 합니다.Link to this heading#

\n

티켓 작업을 할 때는 작업용 새 브랜치를 만들고, 해당 작업은 ``upstream/main``을 기반으로 하세요.

\n
Shell
git checkout -b ticket_xxxxx upstream/main\n
\n

-b 플래그는 로컬로 새 분기를 만듭니다. 작은 일에도 불구하고 새로운 지점을 만드는 것을 주저하지 마십시오. 그것이 바로 그 목적입니다.

\n

대신 1.4 브랜치에서 수정 작업을 하는 경우에는 다음과 같이 합니다.

\n
Shell
git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x\n
\n

작업이 ticket_xxxxx 브랜치에서 진행된다고 가정하고, 변경 사항을 적용한 후 커밋하세요.

\n
Shell
git commit\n
\n

커밋 메시지를 작성할 때 :ref:”커밋 메시지 지침”을 따라 병합 작업을 용이하게 합니다. 만약 영어가 불편하다면, 최소한 그 커밋이 무엇을 하는지 정확하게 설명하도록 노력하세요.

\n

브랜치에서 추가 작업이 필요한 경우, 필요한 만큼 자주 커밋하세요.

\n
Shell
git commit -m 'Added two more tests for edge cases.'\n
\n
\n

게시 작업Link to this heading#

\n

다음을 실행하여 GitHub에 작업을 게시할 수 있습니다.

\n
Shell
git push origin ticket_xxxxx\n
\n

GitHub 페이지로 이동하면 새 분기가 생성되었음을 알 수 있습니다.

\n

Trac 티켓을 작업하는 경우 GitHub repo의 branch ticket_xxxxxx에서 작업을 수행할 수 있음을 티켓에 언급해야 합니다. 분기에 대한 링크를 포함합니다.

\n

위의 분기를 Git parance에서 “토픽 분기”라고 합니다. 예를 들어 “gitrebase”를 사용하여 이 지점의 기록을 자유롭게 다시 작성할 수 있습니다. 커밋을 편집할 때 복제본이 손상되기 때문에 다른 사용자는 이러한 분기에 기반하여 작업을 수행해서는 안 됩니다.

\n

“public branches”도 있습니다. 이것들은 다른 사람들이 포크해야 하는 지점들이기 때문에, 이 지점들의 역사는 절대 바뀌어서는 안 됩니다. 공용 분기의 좋은 예로는 django/django 저장소에 있는 ``main``와 ``stable/A.B.x` 분기가 있습니다.

\n

작업을 Django로 풀 할 준비가 되었다고 생각되면 GitHub에서 풀 요청을 작성해야 합니다. 좋은 풀 요청은 다음을 의미합니다.

\n
    \n

  • 각 커밋에는 하나의 논리적 변경만 포함하도록 하고, :doc:`coding style </internals/contributing/writing-code/coding-style>`을 따르세요.

    • \n

  • 각 커밋에 대한 올바른 형식의 메시지: 요약 줄과 72자로 요약된 단락 - 자세한 내용은 :ref:”커밋 지침”을 참조하십시오.

    • \n

  • 설명서 및 테스트(필요한 경우)는 문서 변경을 제외하고 실제로 항상 테스트가 필요합니다.

    • \n
\n

테스트 제품군을 통과해야 하며 설명서는 경고 없이 작성되어야 합니다.

\n

풀 요청을 만든 후에는 관련 Trac 티켓에 사용자가 수행한 작업을 설명하는 설명을 추가해야 합니다. 특히 “ SQLite 및 MySQL에서 통과하는 모든 테스트”와 같은 테스트를 실행한 환경에 주목해야 합니다.

\n

GitHub의 Pull 요청에는 열린 상태와 닫힌 상태 두 가지 상태만 있습니다. 풀 요청을 처리할 병합에는 병합 또는 닫기의 두 가지 옵션만 있습니다. 이러한 이유로 코드가 병합될 준비가 되거나 병합이 자체적으로 완료될 정도로 충분히 가까워질 때까지 풀 요청을 하는 것은 유용하지 않습니다.

\n
\n
\n

커밋 메시지 수정Link to this heading#

\n

가장 최근 커밋의 메시지를 변경하려면 다음을 실행하세요.

\n
Shell
git commit --amend\n
\n

현재 커밋 메시지가 포함된 편집기가 열립니다. 메시지를 수정하고 저장한 후 닫으면 커밋이 업데이트됩니다.

\n

이전 커밋의 메시지를 변경하려면 대화형 리베이스에서 “reword” 옵션을 사용하세요. 예를 들어 최근 세 개의 커밋 중 하나의 메시지를 수정하려면:

\n
Shell
git rebase -i HEAD~3\n
\n

세 개의 커밋이 나열된 편집기가 열리며, 각 줄 앞에는 “pick”이라는 단어가 붙어 있습니다. 수정하려는 커밋의 줄에서 “pick”을 “reword”(또는 “r”)로 변경한 후 저장하고 닫으세요. 그러면 “reword”로 표시된 각 커밋마다 새로운 편집기가 열려 메시지를 수정할 수 있습니다.

\n

필요한 커밋 메시지 형식은 :ref:`committing-guidelines`에서 확인할 수 있습니다.

\n

이미 GitHub에 푸시된 커밋을 재작성한 경우에는 다음과 같이 브랜치를 강제로 푸시해야 합니다.

\n
Shell
git push --force-with-lease origin ticket_xxxxx\n
\n
\n
\n

브랜치 리베이스하기Link to this heading#

\n

위 예시에서는 “Fixed #xxxxx – …” 커밋과 “Added two more tests …” 커밋, 두 가지를 생성했습니다.

\n

작업 프로세스의 전체 이력을 리포지토리에 저장하지 않습니다. “테스트 두 개 추가”라는 약속은 도움이 되지 않는 잡음이 될 것입니다. 대신, 우리는 당신의 모든 일을 포함하는 하나의 약속만을 원합니다.

\n

브랜치의 히스토리를 재구성하려면, 다음과 같이 대화형 리베이스를 사용하여 커밋을 하나로 스쿼시할 수 있습니다.

\n
Shell
git rebase -i HEAD~2\n
\n

위의 HEAD~2는 최근 두 가지 커밋의 약자입니다. 위의 명령어는 “pick”이라는 단어 앞에 있는 두 개의 커밋을 보여주는 편집기를 엽니다.

\n

대신 두 번째 줄의 “선택”을 “파쇄”로 변경합니다. 이렇게 하면 첫 번째 커밋이 유지되고 두 번째 커밋이 첫 번째 커밋으로 스쿼시됩니다. 편집기를 저장한 후 종료합니다. 두 번째 편집기 창이 열리면 커밋 메시지에 대한 단어를 바꿀 수 있습니다. 이제 커밋 메시지에 두 단계가 모두 포함됩니다.

\n

리베이스에서 “edit” 옵션을 사용할 수도 있습니다. 이 방법을 사용하면 단일 커밋을 수정할 수 있습니다. 예를 들어 docstring의 오타를 수정하는 경우:

\n
Shell
git 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
\n

리뷰를 반영하기 위해 사소한 변경을 하는 경우처럼, 주제 브랜치가 이미 GitHub에 푸시된 상태라면 변경 사항을 강제로 푸시해야 합니다.

\n
Shell
git push --force-with-lease origin ticket_xxxxx\n
\n

이렇게 하면 ticket_xxxxx의 기록이 다시 작성됩니다. GitHub에서 작업 전후에 커밋 해시를 확인하면 커밋 해시가 더 이상 일치하지 않음을 알 수 있습니다. 분기는 주제 분기로, 누구도 작업에 기반을 두어서는 안 되기 때문에 이는 허용됩니다.

\n
\n
\n

업스트림 변경 후.Link to this heading#

\n

업스트림(django/django)이 변경되면 작업을 리베이스하세요. 이를 위해 다음을 사용합니다.

\n
Shell
git fetch upstream\ngit rebase upstream/main\n
\n

이 작업은 “upstream/main”을 사용하는 예에서와 같이 사용자가 분기한 분기를 사용하여 자동으로 리베이스화됩니다.

\n

rebase 명령은 일시적으로 모든 로컬 커밋을 제거하고 업스트림 커밋을 적용한 다음 로컬 커밋을 작업에 다시 적용합니다.

\n

병합 충돌이 있는 경우 이를 해결하고 “gitrebase –continue”를 사용해야 합니다. 언제든지 “git rebase –abort”를 사용하여 원래 상태로 돌아갈 수 있습니다.

\n

업스트림을 *머지*하지 않고 업스트림에 *리베이스*를 지정하려고 합니다.

\n

그 이유는 기본 재배치함으로써 커밋은 항상 업스트림의 작업과 *혼합*되는 것이 아니라 *업스트림의 작업에 *상위*되기 때문입니다. 이렇게 하면 분기에 해당 주제와 관련된 커밋만 포함되므로 쉽게 스퀴싱할 수 있습니다.

\n
\n
\n

검토후Link to this heading#

\n

검토자가 요청한 변경 사항 없이 사소한 양의 코드를 코어로 가져오는 것은 드문 일입니다. 이 경우 변경 사항을 작업에 대한 하나의 증분 커밋으로 추가하는 것이 좋습니다. 이렇게 하면 검토자는 사용자가 변경한 내용을 쉽게 확인할 수 있습니다.

\n

이 경우 검토자가 요청한 변경 사항을 반영하세요. 필요한 만큼 자주 커밋하세요. 변경 내용을 게시하기 전에 작업을 리베이스하세요. 두 개의 커밋을 추가한 경우 다음을 실행합니다.

\n
Shell
git rebase -i HEAD~2\n
\n

두 번째 커밋을 첫 번째 커밋에 합치세요. 다음과 같은 형식으로 커밋 메시지를 작성합니다.

\n
Text
Made changes asked in review by <reviewer>.\n\n- Fixed whitespace errors in foobar.\n- Reworded the docstring of bar().\n
\n

마지막으로 작업을 GitHub 저장소로 다시 푸시하세요. 리베이스 과정에서 공개된 커밋을 변경하지 않았다면 강제 푸시할 필요는 없습니다.

\n
Shell
git push origin ticket_xxxxx\n
\n

이제 풀 요청에도 새 커밋이 포함됩니다.

\n

병합은 코드를 커밋할 때 검토 커밋을 이전 커밋으로 압축할 가능성이 높습니다.

\n
\n
\n
\n

패치 작업 중Link to this heading#

\n

개발자가 Django에 기여할 수 있는 방법 중 하나는 패치를 검토하는 것입니다. 이러한 패치는 일반적으로 GitHub의 pull request 형태로 존재하며, 로컬 저장소에 쉽게 통합할 수 있습니다.

\n
Shell
git checkout -b pull_xxxxx upstream/main\ncurl -L https://github.com/django/django/pull/xxxxx.patch | git am\n
\n

이렇게 하면 새 분기가 생성된 다음 꺼내기 요청의 변경 사항이 해당 분기에 적용됩니다. 이때 테스트를 실행하거나 패치 품질을 조사하는 데 필요한 다른 작업을 수행할 수 있습니다.

\n

풀 요청 작업에 대한 자세한 내용은 :ref:’합병 지침을 참조하십시오.

\n
\n
\n

개요Link to this heading#

\n\n
","rootId":"working-with-git-and-github","toc":[{"title":"GIT 설치","anchor":"installing-git","children":[]},{"title":"로컬 리포지토리를 설정하는 중입니다.","anchor":"setting-up-local-repository","children":[]},{"title":"티켓 작업을 합니다.","anchor":"working-on-a-ticket","children":[{"title":"게시 작업","anchor":"publishing-work","children":[]},{"title":"커밋 메시지 수정","anchor":"editing-commit-messages","children":[]},{"title":"브랜치 리베이스하기","anchor":"rebasing-branches","children":[]},{"title":"업스트림 변경 후.","anchor":"after-upstream-has-changed","children":[]},{"title":"검토후","anchor":"after-review","children":[]}]},{"title":"패치 작업 중","anchor":"working-on-a-patch","children":[]},{"title":"개요","anchor":"summary","children":[]}],"breadcrumbs":[{"docname":"internals/index","title":"Django 내부 구조","url":"/ko/6.1/internals/"},{"docname":"internals/contributing/index","title":"장고에 기여하기","url":"/ko/6.1/internals/contributing/"},{"docname":"internals/contributing/writing-code/index","title":"코드에 기여하기","url":"/ko/6.1/internals/contributing/writing-code/"}],"prev":{"docname":"internals/contributing/writing-code/unit-tests","title":"유닛 테스트","url":"/ko/6.1/internals/contributing/writing-code/unit-tests/"},"next":{"docname":"internals/contributing/writing-code/coding-style","title":"코딩 스타일","url":"/ko/6.1/internals/contributing/writing-code/coding-style/"},"formats":{"html":"/ko/6.1/internals/contributing/writing-code/working-with-git/","markdown":"/ko/6.1/internals/contributing/writing-code/working-with-git.md","json":"/ko/6.1/internals/contributing/writing-code/working-with-git.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/internals/contributing/writing-code/working-with-git.txt","official":"https://docs.djangoproject.com/ko/6.1/internals/contributing/writing-code/working-with-git/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}