In Scott Chacon's workflow (explained eg in this SO answer), with essentially two silos (development, and master), if, say I have a small bug to fix (e.g. can be fixed with a few characters) is the optimal way of doing that:

a) branch off of development a branch called e.g. fix_123. Push this branch to origin as I work on it. When it's done, code-reviewed, whatever, merge into development and push development to origin.

b) Same as above, but without pushing fix_123 to origin.

The premise you are questioning really is wrong:


  that one major advantage of Git over Subversion is that Git gives all the source code to the developer locally


With both Subversion and Git you have your source code locally. With Git you have both your source code and a repository on your local machine.

It goes something like this.

Subversion:

Your code <-> The Repository

Git:

Your code <-> Your local repository <-> A remote repository (... <-> another remote repo, and so on) 

One benefit you get from this structure is that you can still use source control and commit your local changes to your local repository without disturbing the work of other team members (with whom you share the remote repository). 

With Subversion you'd have to either risk breaking the build for other people or suffer prolonged local development without any source control which ends with a huge commit (or more likely a revert).

With Git, on the other hand, you'd feel free to commit these changes to your local repository, view logs and diffs or your changes, and only when you feel it is ready to be shared with the team push the changes from the local repository to the remote one.
