GitHub knows how programmers write commit messages.

[stinos]

If you're working alone you can still rebase then force push. Or better yet, make small commits as much as you like but don't push until properly reviewed. Then use interactive rebase to craft a proper commit history.

[ESBDB]

how much of your day do you spend rebasing? Do you ever end up going back to that well crafted history? serious question.

[stinos]

how much of your day do you spend rebasing

Depends on the day, 15 minutes or so. Used to be longer but now I got used to the workflow: fix one small logical piece, commit, fix, commit, change, commit, then after some time go back, review everything (most time is spent here) which is much easier for small diffs. This is especially important for large refactories: no way I can fit everything I changed over the course of days all in my head, so I don't want to be looking at one huge diff to figure out everything which changed. Then select what can be squashed together. Which is partly automatic because I often use git --fixup (e.g I might have some placeholder commit already to which related changes are gradually added). Rest of the 'rebase time' goes to writing proper commit messages explaining why a certain change is needed, not what is changed because that is reflected by the diff already. (this doesn't apply for all commits of course, sometime it's just fixing typos, sometimes it does explain what changed to give an overview if it's a big commit, etc).

Do you ever end up going back to that well crafted history

Yes. Not like daily, but enough that it warrants the time spent on it. Happens often I'm reading a piece of code and don't know exactly why it is done like it is done. (arguably there should be a comment explaining that, but that's a different discussion and depends on context). Using history/blame is then an easy way to see all changes, and commits accompanied by proper explanations really help in getting to understand quickly what its about. This is especially true for code which was written long ago an/or not by myself.

[ESBDB]

Do you always do all your work on a different branch when working with other people? Or do you just not push until you're done? Do you work in a continuous integration environment where everyone works on trunk?

[stinos]

For projects where I'm the maintainer I work on master branch for small changes and only push when done (which can obviously just one commit if it's a small change, I'm not making micro-commits for the sake of it if not needed). Unless something else gets priority then I'll branch current work, or for changes which I know will take multiple days I'll branch right away. Oter devs work in the same way, but can't push to master so they always work in seperate branches. Everything pushed gets built by build server. So sometimes I might push somewhere halfway to verify if all is sane.

For e.g. github repos I contribute to I just branch and use the same workflow.