@@ -29,14 +29,14 @@ Making a new feature branch
2929
3030::
3131
32- git branch my-new-feature
33- git checkout my-new-feature
32+ git checkout -b my-new-feature master
3433
35- This will create a feature branch based on ``master ``. To create a
36- feature branch based on a maintenance branch, use::
34+ This will create and immediately check out a feature branch based on
35+ ``master ``. To create a feature branch based on a maintenance branch,
36+ use::
3737
38- git branch my-new-feature remotes/ origin/v1.0.x
39- git checkout my-new-feature
38+ git fetch origin
39+ git checkout -b my-new-feature origin/v1.0.x
4040
4141Generally, you will want to keep this also on your public github _ fork
4242of matplotlib _. To do this, you `git push `_ this new branch up to your github _
@@ -54,7 +54,8 @@ using the ``--set-upstream`` option::
5454 git push --set-upstream origin my-new-feature
5555
5656and then next time you need to push changes to your branch a simple
57- ``git push `` will suffice.
57+ ``git push `` will suffice. Note that ``git push `` pushes out all
58+ branches that are linked to a remote branch.
5859
5960The editing workflow
6061====================
@@ -168,7 +169,7 @@ Overview
168169 # pull changes from github
169170 git fetch upstream
170171 # merge from upstream
171- git merge upstream/master
172+ git merge --ff-only upstream/master
172173
173174In detail
174175---------
@@ -188,16 +189,85 @@ the upstream repo to a copy on your local machine::
188189
189190then merging into your current branch::
190191
191- git merge upstream/master
192+ git merge --ff-only upstream/master
193+
194+ The ``--ff-only `` option guarantees that if you have mistakenly
195+ committed code on your ``master `` branch, the merge fails at this point.
196+ If you were to merge ``upstream/master `` to your ``master ``, you
197+ would start to diverge from the upstream. If this command fails, see
198+ the section on accidents _.
192199
193200.. Doesn't one then need to push this up to the private repository? I
194201.. have multiple machines I use for development, and I don't want to
195202.. have to do this on all of them - MGD
196203
204+ .. Not really; does the paragraph below explain this enough? - JKS
205+
206+ The letters 'ff' in ``--ff-only `` mean 'fast forward', which is a
207+ special case of merge where git can simply update your branch to point
208+ to the other branch and not do any actual merging of files. For
209+ ``master `` and other integration branches this is exactly what you
210+ want.
211+
197212.. Does this need to be done for each maintenance branch as well?
198213.. This doesn't seem to be sufficient to pull in changes on an
199214.. upstream maintenance branch. - MGD
200215
216+ .. Does the section below answer this? - JKS
217+
218+ Other integration branches
219+ --------------------------
220+
221+ Some people like to keep separate local branches corresponding to the
222+ maintenance branches on github. At the time of this writing, ``v1.0.x ``
223+ is the active maintenance branch. If you have such a local branch,
224+ treat is just as ``master ``: don't commit on it, and before starting
225+ new branches off of it, update it from upstream::
226+
227+ git checkout v1.0.x
228+ git fetch upstream
229+ git merge --ff-only upstream/v1.0.x
230+
231+ But you don't necessarily have to have such a branch. Instead, if you
232+ are preparing a bugfix that applies to the maintenance branch, fetch
233+ from upstream and base your bugfix on the remote branch;:
234+
235+ git fetch upstream
236+ git checkout -b my-bug-fix upstream/v1.0.x
237+
238+ .. _accidents :
239+
240+ Recovering from accidental commits on master
241+ --------------------------------------------
242+
243+ If you have accidentally committed changes on ``master `` and
244+ ``git merge --ff-only `` fails, don't panic! First find out how much
245+ you have diverged::
246+
247+ git diff upstream/master...master
248+
249+ If you find that you want simply to get rid of the changes, reset
250+ your ``master `` branch to the upstream version::
251+
252+ git reset --hard upstream/master
253+
254+ As you might surmise from the words 'reset' and 'hard', this command
255+ actually causes your changes to the current branch to be lost, so
256+ think twice.
257+
258+ If, on the other hand, you find that you want to preserve the changes,
259+ create a feature branch for them::
260+
261+ git checkout -b my-important-changes
262+
263+ Now ``my-important-changes `` points to the branch that has your
264+ changes, and you can safely reset ``master `` as above |emdash | but
265+ make sure to reset the correct branch::
266+
267+ git checkout master
268+ git reset --hard upstream/master
269+
270+
201271Deleting a branch on github _
202272============================
203273
0 commit comments