>That leaves you prone to losing work if you have a false start that you need to back out of.
Hasn't happened to me in over 20 years of using version control. I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same. If I wanted to try a new direction I'd just clone the repo again and do the work there. Littering the git history with dozens of superfluous commits just seems pointless. Having to stop and think about writing a commit comment is also just a waste of time - in aggregate it wastes a lot of time. It adds a lot of churn to a workflow for something that may never really be of any value.
> Littering the git history with dozens of superfluous commits just seems pointless.
This is where the final rebase comes in—you should be combining all the small commits into one.
> Having to stop and think about writing a commit comment is also just a waste of time
Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.
> I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same.
You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?
>This is where the final rebase comes in—you should be combining all the small commits into one.
Sorry, but I'm a software engineer, not a git engineer, and the less I have to do with git, the better. KISS applies to git, too. A simple thing like not creating a commit for every stupid thing keeps the history clean, doesn't bog down the developer by requiring to think about writing a commit message every 2 minutes, and keeps git simple.
>Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.
But then what value have you added by naming everything "draft" and creating a commit? There is no value in doing this.
>You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?
Sure I have, but I don't need to enter it into the git logs. I'll either start over in a clone of the repo if I want to save the bad work for whatever reason (which is very unlikely), or I'll just stash the work, or whatever. The thing I don't need to do is commit the bad work.
Hasn't happened to me in over 20 years of using version control. I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same. If I wanted to try a new direction I'd just clone the repo again and do the work there. Littering the git history with dozens of superfluous commits just seems pointless. Having to stop and think about writing a commit comment is also just a waste of time - in aggregate it wastes a lot of time. It adds a lot of churn to a workflow for something that may never really be of any value.