[1.10.x] Fixed a few grammar issues in working-with-git doc.

Backport of 4f113483d7 from master

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