Fixed a few grammar issues in working-with-git doc.
This commit is contained in:
parent
3569ba0333
commit
4f113483d7
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue