diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index a7588361f2..00f9b79c09 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -7,7 +7,7 @@ requests. If you're interested in how core developers 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 +changes for Trac ticket #xxxxx. By creating a fully-ready pull request, you will make the reviewer's job easier, meaning that your work is more likely to be merged into Django. @@ -24,7 +24,7 @@ your operating system's package manager. 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 setup your name and +After installing Git, the first thing you should do is setup your name and email:: $ git config --global user.name "Your Real Name" @@ -48,7 +48,7 @@ forked Django's repository, create a local copy of your fork:: 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:: +cloned directory, so switch to it now:: cd django @@ -67,7 +67,7 @@ You can add other remotes similarly, for example:: Working on a ticket =================== -When working on a ticket create a new branch for the work, and base that work +When working on a ticket, create a new branch for the work, and base that work on upstream/master:: git checkout -b ticket_xxxxx upstream/master @@ -79,7 +79,7 @@ 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 ticket_xxxxx branch. Make some changes and +Assume the work is carried on the ticket_xxxxx branch. Make some changes and commit them:: git commit @@ -101,7 +101,7 @@ You can publish your work on GitHub just by doing:: git push origin ticket_xxxxx -When you go to your GitHub page you will notice a new branch has been created. +When you go to your GitHub page, you will notice a new branch has been created. If you are working on a Trac ticket, you should mention in the ticket that your work is available from branch ticket_xxxxx of your GitHub repo. Include a @@ -133,7 +133,7 @@ a pull request at GitHub. A good pull request means: The test suite must pass and the documentation must build without warnings. Once you have created your pull request, you should add a comment in the -related Trac ticket explaining what you've done. In particular you should note +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". @@ -146,7 +146,7 @@ himself. Rebasing branches ----------------- -In the example above you created two commits, the "Fixed ticket_xxxxx" commit +In the example above, you created two commits, the "Fixed ticket_xxxxx" commit and "Added two more tests" commit. We do not want to have the entire history of your working process in your @@ -174,7 +174,7 @@ commit, for example to fix a typo in a docstring:: # 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 + # Reword the commit message if needed git rebase --continue # The second and third commits should be applied. @@ -186,7 +186,7 @@ push the changes:: Note that this will rewrite history of ticket_xxxxx - if you check the commit hashes before and after the operation at GitHub you will notice that the -commit hashes do not match any more. This is acceptable, as the branch is merely +commit hashes do not match anymore. This is acceptable, as the branch is merely a topic branch, and nobody should be basing their work on it. After upstream has changed @@ -204,7 +204,7 @@ example case using upstream/master. The rebase command removes all your local commits temporarily, applies the upstream commits, and then applies your local commits again on the work. -If there are merge conflicts you will need to resolve them and then use ``git +If there are merge conflicts, you will need to resolve them and then use ``git rebase --continue``. At any point you can use ``git rebase --abort`` to return to the original state. @@ -237,7 +237,7 @@ of:: - Fixed whitespace errors in foobar - Reworded the docstring of bar() -Finally push your work back to your GitHub repository. Since you didn't touch +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