1.. highlight:: bash 2 3.. _maintainer-workflow: 4 5################### 6Maintainer workflow 7################### 8 9This page is for maintainers |emdash| those of us who merge our own or other 10peoples' changes into the upstream repository. 11 12Being as how you're a maintainer, you are completely on top of the basic stuff 13in :ref:`development-workflow`. 14 15The instructions in :ref:`linking-to-upstream` add a remote that has read-only 16access to the upstream repo. Being a maintainer, you've got read-write access. 17 18It's good to have your upstream remote have a scary name, to remind you that 19it's a read-write remote:: 20 21 git remote add upstream-rw git@github.com:matplotlib/matplotlib.git 22 git fetch upstream-rw 23 24******************* 25Integrating changes 26******************* 27 28Let's say you have some changes that need to go into trunk 29(``upstream-rw/master``). 30 31The changes are in some branch that you are currently on. For example, you are 32looking at someone's changes like this:: 33 34 git remote add someone git://github.com/someone/matplotlib.git 35 git fetch someone 36 git branch cool-feature --track someone/cool-feature 37 git checkout cool-feature 38 39So now you are on the branch with the changes to be incorporated upstream. The 40rest of this section assumes you are on this branch. 41 42A few commits 43============= 44 45If there are only a few commits, consider rebasing to upstream:: 46 47 # Fetch upstream changes 48 git fetch upstream-rw 49 # rebase 50 git rebase upstream-rw/master 51 52Remember that, if you do a rebase, and push that, you'll have to close any 53github pull requests manually, because github will not be able to detect the 54changes have already been merged. 55 56A long series of commits 57======================== 58 59If there are a longer series of related commits, consider a merge instead:: 60 61 git fetch upstream-rw 62 git merge --no-ff upstream-rw/master 63 64The merge will be detected by github, and should close any related pull requests 65automatically. 66 67Note the ``--no-ff`` above. This forces git to make a merge commit, rather than 68doing a fast-forward, so that these set of commits branch off trunk then rejoin 69the main history with a merge, rather than appearing to have been made directly 70on top of trunk. 71 72Check the history 73================= 74 75Now, in either case, you should check that the history is sensible and you have 76the right commits:: 77 78 git log --oneline --graph 79 git log -p upstream-rw/master.. 80 81The first line above just shows the history in a compact way, with a text 82representation of the history graph. The second line shows the log of commits 83excluding those that can be reached from trunk (``upstream-rw/master``), and 84including those that can be reached from current HEAD (implied with the ``..`` 85at the end). So, it shows the commits unique to this branch compared to trunk. 86The ``-p`` option shows the diff for these commits in patch form. 87 88Push to trunk 89============= 90 91:: 92 93 git push upstream-rw my-new-feature:master 94 95This pushes the ``my-new-feature`` branch in this repository to the ``master`` 96branch in the ``upstream-rw`` repository. 97 98.. include:: links.inc 99