So here's a tip I just found out, via (of course) Stackoverflow.

Say you have been working on some Javascript for a bit, and you want to go home. So, like a good software engineer (or ninja rockstar developer) you commit your source changes in semantically separated pieces, using:

git commit -p src/

to get git to propose hunks to add to your commits. You end up with a nice list of commits, like this:

* 9034a53 2016-02-26 refs #AG-44 @2h - add new SinglePartPicker  (HEAD -> AG-44) <Tom Macdonald>
* 02233ec 2016-02-26 refs #AG-44 @2h - speed up double part selector  <Tom Macdonald>
* e8c0665 2016-02-26 refs #AG-44 - some cleanups  <Tom Macdonald>
* ec7e28f 2016-02-26 refs #AG-44 @1h - get options saving properly again  <Tom Macdonald>
* 54aef42 2016-02-26 refs #AG-44 @1h - Another awesome commit message from ->  <Tom Macdonald>

and all is good. Then you realize that there is one file in the doc/ folder which is semantically related to commit ec7e28f, and should be in the same commit. Obviously you commit the file and use

git rebase -i 54aef42

and use the fixup command.

But you can do better!

If you commit the file with a message that looks like this:

git commit -m 'fixup! ec7e28f'

and then run

git rebase -i 54aef42 --autosquash

then git will automatically move the new commit to just below ec7e28f in the rebase menu. All you have to do is save and exit, and git will squash the new commit into the semantically related ec728f without modifying the commit message.

Fast and effective. I like it.