|   20 +++++----
 ...
$ git reset --merge ORIG_HEAD      <2>
------------
+
<1> Even if you may have local modifications in your
    working tree, you can safely say `git pull` when you know
    that the change in the other branch does not overlap with
    them.
<2> After inspecting the result of the merge, you may find
    that the change in the other branch is unsatisfactory.  Running
    `git reset --hard ORIG_HEAD` will let you go back to where you
    were, but it will discard your local changes, which you do not
    want.  `git reset --merge` keeps your local changes.


Interrupted workflow::
+
Suppose you are interrupted by an urgent fix request while you
are in the middle of a large change.  The files in your
working tree are not in any shape to be committed yet, but you
need to get to the other branch for a quick bugfix.
+
------------
$ git switch feature  ;# you were working in "feature" branch and
$ work work work      ;# got interrupted
$ git commit -a -m "snapshot WIP"                 <1>
$ git switch master
$ fix fix fix
$ git commit ;# commit with real log
$ git switch feature
$ git reset --soft HEAD^ ;# go back to WIP state  <2>
$ git reset                                       <3>
------------
+
<1> This commit will get blown away so a throw-away log message is OK.
<2> This removes the 'WIP' commit from the commit history, and sets
    your working tree to the state just before you made that snapshot.
<3> At this point the index file still has all the WIP changes you
    committed as 'snapshot WIP'.  This updates the index to show your
    WIP files as uncommitted.
+
See also linkgit:git-stash[1].

Reset a single file in the index::
+
Suppose you have added a file to your index, but later decide you do not
want to add it to your commit. You can remove the file from the index
while keeping your changes with git reset.
+
------------
$ git reset -- frotz.c                      <1>
$ git commit -m "Commit files in index"     <2>
$ git add frotz.c                           <3>
------------
+
<1> This removes the file from the index while keeping it in the working
    directory.
<2> This commits all other changes in the index.
<3> Adds the file to the index again.

Keep changes in working tree while discarding some previous commits::
+
Suppose you are working on something and you commit it, and then you
continue working a bit more, but now you think that what you have in
your working tree should be in another branch that has nothing to do
with what you committed previously. You can start a new branch and
reset it while keeping the changes in your working tree.
+
------------
$ git tag start
$ git switch -c branch1
$ edit
$ git commit ...                            <1>
$ edit
$ git switch -c branch2                     <2>
$ git reset --keep start                    <3>
------------
+
<1> This commits your first edits in `branch1`.
<2> In the ideal world, you could have realized that the earlier
    commit did not belong to the new topic when you created and switched
    to `branch2` (i.e. `git switch -c branch2 start`), but nobody is
    perfect.
<3> But you can use `reset --keep` to remove the unwanted commit after
    you switched to `branch2`.

Split a commit apart into a sequence of commits::
+
Suppose that you have created lots of logically separate changes and committed
them together. Then, later you decide that it might be better to have each
logical chunk associated with its own commit. You can use git reset to rewind
history without changing the contents of your local files, and then successively
use `git add -p` to interactively select which hunks to include into each commit,
using `git commit -c` to pre-populate the commit message.
+
------------
$ git reset -N HEAD^                        <1>
$ git add -p                                <2>
$ git diff --cached                         <3>
$ git commit -c HEAD@{1}                    <4>
...                                         <5>
$ git add ...