This will create and immediately check out a feature branch based on
master. To create a feature branch based on a maintenance branch,
use:

git fetch origin
git checkout -b my-new-feature origin/v1.0.x

Generally, you will want to keep this also on your public github fork
of matplotlib. To do this, you git push this new branch up to your github
repo. Generally (if you followed the instructions in these pages, and
by default), git will have a link to your github repo, called
origin. You push up to your own repo on github with:

git push origin my-new-feature

You will need to use this exact command, rather than simply gitpush every time you want to push changes on your feature branch to
your github repo. However, in git >1.7 you can set up a link by
using the --set-upstream option:

git push --set-upstream origin my-new-feature

and then next time you need to push changes to your branch a simple
gitpush will suffice. Note that gitpush pushes out all
branches that are linked to a remote branch.

Add any new files to version control gitaddnew_file_name (see
git add).

To commit all modified files into the local copy of your repo,, do
gitcommit-am'Acommitmessage'. Note the -am options to
commit. The m flag just signals that you’re going to type a
message on the command line. The a flag — you can just take on
faith — or see why the -a flag? — and the helpful use-case
description in the tangled working copy problem. The git commit manual
page might also be useful.

To push the changes up to your forked repo on github, do a gitpush (see gitpush).

The generated comparison, is between your feature branch
my-new-feature, and the place in master from which you branched
my-new-feature. In other words, you can keep updating master
without interfering with the output from the comparison. More detail?
Note the three dots in the URL above (master...my-new-feature) and
see Two and three dots in difference specs.

Go to the URL of your forked repo, say
http://github.com/your-user-name/matplotlib.git.

Click on the ‘Pull request’ button:

Enter a message; we suggest you select only matplotlib as the
recipient. The message will go to the matplotlib mailing list. Please
feel free to add others from the list as you like.

If the branch is to be merged into a maintenance branch on the main
repo, make sure the “base branch” indicates the maintenance branch
and not master. Github can not automatically determine the branch
to merge into.

Merge the upstream code into your current development by first pulling
the upstream repo to a copy on your local machine:

git fetch upstream

then merging into your current branch:

git merge --ff-only upstream/master

The --ff-only option guarantees that if you have mistakenly
committed code on your master branch, the merge fails at this point.
If you were to merge upstream/master to your master, you
would start to diverge from the upstream. If this command fails, see
the section on accidents.

The letters ‘ff’ in --ff-only mean ‘fast forward’, which is a
special case of merge where git can simply update your branch to point
to the other branch and not do any actual merging of files. For
master and other integration branches this is exactly what you
want.

Some people like to keep separate local branches corresponding to the
maintenance branches on github. At the time of this writing, v1.0.x
is the active maintenance branch. If you have such a local branch,
treat is just as master: don’t commit on it, and before starting
new branches off of it, update it from upstream: