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.
Ideally push it to origin as that means everybody else will see that someone else is working on a fix. Also even though something is a small fix when measured by number of charecters it can make a huge difference in execution so the size of the fix shouldn’t make any difference to the way you fix it.
However practically when I used git it took so long to sync that I’d bundle a group of small fixes together and just let other devs know by email that I was working on them.
3
It really depends on this. I commit frantically locally but only commit (presumably working) milestones to the remote repository. Historically, the 1000’s of local commits don’t add as much value to the greater code base as the feature level stuff does (IMO). It creates clutter (IMO).
If your fix_123 is a complete and functional commit, perhaps a bug fix or some other isolated task, it makes more sense to commit each of these to development. If bug number 10402030 is reported and your commit and push from local only encompasses the complete fix state that isn’t such a bad thing.
One way to limit clutter on the remote repository is to squash some commits by rebasing like mentioned HERE. I only use git in personal projects outside of my paid work so if I am flawed in my methods I don’t mind corrective comments.
On all this, version control practices can almost be like discussing religion. You will get wildly different opinions and practices but it really depends on what fits the project and organization.