코드 커밋¶

pull requests 처리¶

장고는 깃허브에서 호스팅되기 때문에 패치는 pull requests 형태로 제공된다.

When committing a pull request, make sure each individual commit matches the commit guidelines described below. Contributors are expected to provide the best pull requests possible. In practice mergers - who will likely be more familiar with the commit guidelines - may decide to bring a commit up to standard themselves.

Jenkins 또는 GitHub 작업이 Oracle 또는 Selenium과 같이 자동으로 실행되지 않는 pull request 빌더 중 하나를 사용하여 pull request를 테스트하도록 할 수 있습니다. 자세한 내용은 ‘CI Wiki 페이지’_를 참조하십시오.

If you find yourself checking out pull requests locally more often, this git alias will be helpful:

[alias]
    pr = !sh -c \"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\"

“~.gitconfig”에 추가하고 “upstream”을 “django/django”로 설정합니다. 그런 다음 “gitpr ###”을 실행하여 해당 pull request를 확인할 수 있습니다.

이 시점에서 코드를 작업할 수 있습니다. “git rebase -i” 및 “git commit –amend”를 사용하여 커밋의 퀄리티가 예상된 수준인지 확인합니다. 준비가 되면:

$ # Pull in the latest changes from main.
$ git checkout main
$ git pull upstream main
$ # Rebase the pull request on main.
$ git checkout pr/####
$ git rebase main
$ git checkout main
$ # Merge the work as "fast-forward" to main to avoid a merge commit.
$ # (in practice, you can omit "--ff-only" since you just rebased)
$ git merge --ff-only pr/XXXX
$ # If you're not sure if you did things correctly, check that only the
$ # changes you expect will be pushed to upstream.
$ git push --dry-run upstream main
$ # Push!
$ git push upstream main
$ # Delete the pull request branch.
$ git branch -d pr/xxxx

...\> REM Pull in the latest changes from main.
...\> git checkout main
...\> git pull upstream main
...\> REM Rebase the pull request on main.
...\> git checkout pr/####
...\> git rebase main
...\> git checkout main
...\> REM Merge the work as "fast-forward" to main to avoid a merge commit.
...\> REM (in practice, you can omit "--ff-only" since you just rebased)
...\> git merge --ff-only pr/XXXX
...\> REM If you're not sure if you did things correctly, check that only the
...\> REM changes you expect will be pushed to upstream.
...\> git push --dry-run upstream main
...\> REM Push!
...\> git push upstream main
...\> REM Delete the pull request branch.
...\> git branch -d pr/xxxx

주 베이스 리베이스 후 업스트림으로 병합 및 푸시하기 전에 분기로 강제 푸시합니다. 이렇게 하면 메인 및 분기의 커밋 해시가 일치하여 풀 요청이 자동으로 닫힙니다.

풀 요청을 여러 커밋으로 병합할 필요가 없는 경우 웹 사이트에서 GitHub의 “Squash and merge” 버튼을 사용할 수 있습니다. 필요에 따라 커밋 메시지를 편집하여 지침 ‘:ref:’에 준거하고 메시지의 첫 번째 줄에 자동으로 추가된 풀 요청 번호를 제거합니다.

꺼내기 요청의 커밋 이력을 다시 쓸 때 목표는 장고의 커밋 이력을 가능한 한 사용할 수 있게 만드는 것입니다.

• 패치에 앞뒤로 커밋이 포함된 경우 해당 커밋을 하나로 다시 씁니다. 예를 들어, 커밋이 일부 코드를 추가하고 두 번째 커밋이 첫 번째 커밋에서 도입된 스타일 문제를 수정하는 경우, 이러한 커밋은 병합하기 전에 스쿼시해야 합니다.

• 논리 그룹별로 다른 커밋에 대한 변경 내용 구분: 파일에 대한 다른 변경사항과 동시에 스타일 정리를 수행하는 경우 변경 내용을 두 개의 다른 커밋으로 분리하면 기록을 쉽게 검토할 수 있습니다.

• 풀 요청에서 업스트림 브랜치 병합에 주의하십시오.

• 테스트는 통과해야 하며 각 커밋 후에 문서를 작성해야 합니다. 검사나 문서 중 어느 것도 경고를 발하지 않아야 합니다.

• 일반적으로 사소한 패치와 작은 패치는 한 번의 커밋으로 수행하는 것이 가장 좋습니다. 중대형 작업은 의미가 있는 경우 여러 커밋으로 분할될 수 있습니다.

실용성은 순수함을 능가하므로, pull request를 위해 얼마나 많은 역사를 망칠지 결정하는 것은 각 merge에 달려 있습니다. 주요 포인트는 커뮤니티 참여, 작업 완료, 사용 가능한 커밋 기록 보유입니다.

커밋 가이드라인.¶

또한 Django의 Git 저장소에 코드를 커밋할 때는 다음 지침을 따르십시오.

• “django/django” 지부의 출판 역사를 절대 억지로 밀어붙여서는 안 됩니다. 꼭 필요한 경우 (예를 들어 보안상의 이유로) 먼저 팀과 상황에 대해 논의합니다.

• For any medium-to-big changes, where “medium-to-big” is according to your judgment, please bring things up on the Django Forum before making the change.

  If you bring something up and nobody responds, please don’t take that to mean your idea is great and should be implemented immediately because nobody contested it. Everyone doesn’t always have a lot of time to read discussions immediately, so you may have to wait a couple of days before getting a response.

• 자세한 커밋 메시지를 현재 시제가 아닌 과거 시제로 작성하세요.

  • 좋은예: “RSS API에서 유니코드 버그를 수정했습니다.”

  • 나쁜예: “RSS API에서 유니코드 버그를 수정합니다.”

  • 나쁜예:”RSS API에서 유니코드 버그를 수정하는 중입니다.”

  커밋 메시지는 최대 72자 행이어야 합니다. 빈 줄과 72자 행의 단락으로 구분된 제목 줄이 있어야 합니다. 제한은 고정이 아닙니다. 제목 줄의 경우 짧은 것이 좋습니다. 커밋 메시지의 본문에는 세부 정보가 많은것이 적은 것보다 더 낫습니다.

  Fixed #18307 -- Added git workflow guidelines.
  
  Refactored the Django's documentation to remove mentions of SVN
  specific tasks. Added guidelines of how to use Git, GitHub, and
  how to use pull request together with Trac instead.
  

  커밋 메시지에서 “보고서 A와 검토 B에 감사한다”의 기여자를 평가합니다. git의 Co-Authored-By_를 적절히 사용하세요.

• 분기에 대한 커밋의 경우 커밋 메시지 앞에 분기 이름을 붙입니다. 예를 들어, “[1.4.x] 고정 #xxxxx - 마인드 판독에 대한 지원이 추가되었습니다.”

• 가장 세밀한 변경 사항으로 커밋을 제한합니다. 즉, 큰 커밋은 자주 사용하지 않고 작은 커밋을 자주 사용합니다. 예를 들어, 기능 X를 구현하기 위해 라이브러리 Y에 대한 작은 변경이 필요한 경우, 먼저 변경사항을 라이브러리 Y에 커밋한 다음 별도의 커밋에서 기능 X를 커밋합니다. 이는 모든 사람이 귀사의 변화를 따르도록 돕는 데 큰 도움이 됩니다.

• 기능 변경과 버그 수정을 구분합니다. 버그 픽스는 :ref:’supported-versions-policy’에 따라 안정적인 분기로 백포트해야 할 수 있습니다.

• 커밋이 Django “ticket tracker”에서 티켓을 닫는 경우 커밋 메시지를 “Fixed #xxxxx” 텍스트로 시작합니다. 여기서 “xxxxx”는 커밋이 수정하는 티켓 번호입니다. 예: “고정 #123 - Whizbang 기능 추가” 해당 형식의 커밋 메시지가 자동으로 참조된 티켓을 닫고 전체 커밋 메시지와 함께 의견을 게시하도록 Trac을 조정했습니다.

  궁금하신 분들을 위해 우리는 Trac plugin_을 사용하고 있습니다.

• 커밋이 Django “ticket tracker”_의 티켓을 참조하지만 *티켓을 닫지 않는 경우 “Refs #xxxx” 구문을 포함하십시오. 여기서 “xxxxx”는 커밋이 참조하는 티켓 번호입니다. 그러면 해당 티켓에 대한 설명이 자동으로 게시됩니다.

• 다음 패턴을 사용하여 백포트에 대한 커밋 메시지를 작성합니다.

  [<Django version>] Fixed <ticket> -- <description>
  
  Backport of <revision> from <branch>.
  

  예시:

  [1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net.
  
  Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main.
  

  이를 자동화할 수 있는 스크립트(wiki <https://code.djangoproject.com/wiki/MergerTips#AutomatingBackports>_)가 있습니다.

  커밋이 회귀 분석을 수정하는 경우 커밋 메시지에 다음을 포함합니다.

  Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.
  

  (회귀가 도입된 커밋 해시를 사용합니다.)

커밋 되돌리기¶

완벽한 사람은 없습니다. 실수가 있을 것입니다.

But try very hard to ensure that mistakes don’t happen. Just because we have a reversion policy doesn’t relax your responsibility to aim for the highest quality possible. Really: double-check your work, or have it checked by another merger before you commit it in the first place!

잘못된 커밋이 발견되면 다음 지침을 따르십시오.

• 가능한 경우, 원본 작성자가 자신의 커밋을 되돌리도록 합니다.

• 다른 작성자의 변경 내용을 원본 작성자의 허가 없이 되돌리지 마십시오.

• git revert 사용 - 역 커밋을 수행하지만 원래 커밋은 커밋 히스토리의 부분에 있을것입니다.

• If the original author can’t be reached (within a reasonable amount of time – a day or so) and the problem is severe – crashing bug, major test failures, etc. – then ask for objections on the Django Forum then revert if there are none.

• 문제가 작을 경우(예: 기능이 정지된 후 커밋됨) 대기합니다.

• If there’s a disagreement between the merger and the reverter-to-be then try to work it out on the Django Forum . If an agreement can’t be reached then it should be put to a vote.

• 커밋이 확인되고 공개된 보안 취약성을 도입한 경우 다른 사람의 허가 없이 커밋을 즉시 되돌릴 수 있습니다.

• 릴리스 분기 유지 관리자는 커밋이 릴리스 분기를 중단하는 경우 허가 없이 릴리스 분기로 커밋을 백업할 수 있습니다.

• 주제 분기를 “django/django”로 잘못 누른 경우 삭제하십시오. 예를 들어 “git push upstream feature_antigravity”를 실행했다면 “git push upstream:feature_antigravity”를 역push 하십시오.