# Django 5.2.9 문서

# Git 및 GitHub와 함께 작업

This section explains how the community can contribute code to Django via pull requests. If you’re interested in how mergers handle them, see pull requests 처리.

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

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

## GIT 설치

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

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

After installing Git, the first thing you should do is set up your name and email:

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

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

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

When you have created your GitHub account, with the nick “GitHub_nick”, and forked Django’s repository, create a local copy of your fork:

    git clone https://github.com/GitHub_nick/django.git

This will create a new directory “django”, containing a clone of your GitHub repository. The rest of the git commands on this page need to be run within the cloned directory, so switch to it now:

    cd django

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

You should also set up `django/django` as an “upstream” remote (that is, tell git that the reference Django repository was the source of your fork of it):

    git remote add upstream https://github.com/django/django.git
    git fetch upstream

You can add other remotes similarly, for example:

    git remote add akaariai https://github.com/akaariai/django.git

## 티켓 작업을 합니다.

When working on a ticket, create a new branch for the work, and base that work on `upstream/main`:

    git checkout -b ticket_xxxxx upstream/main

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

If instead you were working for a fix on the 1.4 branch, you would do:

    git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x

Assume the work is carried on the ticket_xxxxx branch. Make some changes and commit them:

    git commit

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

If you need to do additional work on your branch, commit as often as necessary:

    git commit -m 'Added two more tests for edge cases'

### 게시 작업

You can publish your work on GitHub by running:

    git push origin ticket_xxxxx

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

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

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

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

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

- commits with one logical change in each, following the coding style,

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

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

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

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

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

### 브랜치 리베이스하기

위의 예에서는 “Fixed ticket_xxxx” 커밋과 “Test 2개 추가” 커밋이라는 두 가지 커밋을 만들었습니다.

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

To rework the history of your branch you can squash the commits into one by using interactive rebase:

    git rebase -i HEAD~2

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

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

You can also use the “edit” option in rebase. This way you can change a single commit, for example to fix a typo in a docstring:

    git rebase -i HEAD~3
    # Choose edit, pick, pick for the commits
    # Now you are able to rework the commit (use git add normally to add changes)
    # When finished, commit work with "--amend" and continue
    git commit --amend
    # Reword the commit message if needed
    git rebase --continue
    # The second and third commits should be applied.

If your topic branch is already published at GitHub, for example if you’re making minor changes to take into account a review, you will need to force-push the changes:

    git push -f origin ticket_xxxxx

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

### 업스트림 변경 후.

When upstream (`django/django`) has changed, you should rebase your work. To do this, use:

    git fetch upstream
    git rebase upstream/main

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

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

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

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

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

### 검토후

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

In this case, do the changes required by the reviewer. Commit as often as necessary. Before publishing the changes, rebase your work. If you added two commits, you would run:

    git rebase -i HEAD~2

Squash the second commit into the first. Write a commit message along the lines of:

    Made changes asked in review by <reviewer>

    - Fixed whitespace errors in foobar
    - Reworded the docstring of bar()

Finally, push your work back to your GitHub repository. Since you didn’t touch the public commits during the rebase, you should not need to force-push:

    git push origin ticket_xxxxx

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

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

## 패치 작업 중

One of the ways that developers can contribute to Django is by reviewing patches. Those patches will typically exist as pull requests on GitHub and can be easily integrated into your local repository:

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

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

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

## 개요

- 가능하면 GitHub에서 작업하십시오.

- GitHub 브랜치에 링크하여 Trac 티켓에 대한 작업을 공지합니다.

- 준비가 되면 풀 요청을 하세요.

- 가능한 한 풀 요청을 하세요.

- 작업을 수정할 때는 “git rebase -i”를 사용하여 커밋을 스쿼시합니다.

- 업스트림이 변경되면 “git fetch upstream; git rebase”를 수행합니다.