diff options
Diffstat (limited to 'docs/internals/contributing/writing-code/working-with-git.txt')
| -rw-r--r-- | docs/internals/contributing/writing-code/working-with-git.txt | 23 |
1 files changed, 11 insertions, 12 deletions
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 1a70579845..1c9b660c07 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -3,8 +3,8 @@ Working with Git and GitHub =========================== This section explains how the community can contribute code to Django via pull -requests. If you're interested in how committers handle them, see -:doc:`../committing-code`. +requests. If you're interested in how :ref:`mergers <mergers-team>` handle +them, see :doc:`../committing-code`. Below, we are going to show how to create a GitHub pull request containing the changes for Trac ticket #xxxxx. By creating a fully-ready pull request, you @@ -86,9 +86,9 @@ commit them:: git commit When writing the commit message, follow the :ref:`commit message -guidelines <committing-guidelines>` to ease the work of the committer. If -you're uncomfortable with English, try at least to describe precisely what the -commit does. +guidelines <committing-guidelines>` to ease the work of the merger. If you're +uncomfortable with English, try at least to describe precisely what the commit +does. If you need to do additional work on your branch, commit as often as necessary:: @@ -138,11 +138,10 @@ related Trac ticket explaining what you've done. In particular, you should note the environment in which you ran the tests, for instance: "all tests pass under SQLite and MySQL". -Pull requests at GitHub have only two states: open and closed. The committer -who will deal with your pull request has only two options: merge it or close -it. For this reason, it isn't useful to make a pull request until the code is -ready for merging -- or sufficiently close that a committer will finish it -themselves. +Pull requests at GitHub have only two states: open and closed. The merger who +will deal with your pull request has only two options: merge it or close it. +For this reason, it isn't useful to make a pull request until the code is ready +for merging -- or sufficiently close that a merger will finish it themselves. Rebasing branches ----------------- @@ -245,7 +244,7 @@ the public commits during the rebase, you should not need to force-push:: Your pull request should now contain the new commit too. -Note that the committer is likely to squash the review commit into the previous +Note that the merger is likely to squash the review commit into the previous commit when committing the code. Working on a patch @@ -263,7 +262,7 @@ to it. At this point you can run the tests or do anything else you need to do to investigate the quality of the patch. For more detail on working with pull requests see the -:ref:`guidelines for committers <handling-pull-requests>`. +:ref:`guidelines for mergers <handling-pull-requests>`. Summary ======= |