I've been doing this basically since I started using git ~9 years ago. I always work on dev/myfeature branch, and then commit when some tests pass, or I establish a code structure that I think will last.
It's often a tactic of "make the change easy, and then make the easy change". So the first few changes make the change easy -- they are refactoring to prepare for a behavior change.
Then often the last commit is small and has all the behavior change.
Now it's big enough to describe / review. So I do a git diff master.. , make sure it's what I want, run a wider set of tests, squash the commits, write a description, and merge.
In my mind these tactics makes going forward faster. I don't have to check every box before making progress. I'd say 95% of time I just keep piling on commits in the "happy path".
But 5% of the time, on a particularly tricky bug/feature, I might go backward, and this method saves me time. I don't have to worry about polluting the master branch.
-----
Before git I didn't really have a decoupling of "commits" and "work that could be pushed". I was usually working on one big commit. I appreciate this flexibility in keeping track of "code maturity". The master branch should always be kept working with all tests passing.
But I often want to save code in "less good" states. And it even helps if I'm on a desktop and want to move to a laptop to change locations. I just push to the dev branch and then pull on the laptop, without messing up the master.
It's often a tactic of "make the change easy, and then make the easy change". So the first few changes make the change easy -- they are refactoring to prepare for a behavior change.
Then often the last commit is small and has all the behavior change.
Now it's big enough to describe / review. So I do a git diff master.. , make sure it's what I want, run a wider set of tests, squash the commits, write a description, and merge.
In my mind these tactics makes going forward faster. I don't have to check every box before making progress. I'd say 95% of time I just keep piling on commits in the "happy path".
But 5% of the time, on a particularly tricky bug/feature, I might go backward, and this method saves me time. I don't have to worry about polluting the master branch.
-----
Before git I didn't really have a decoupling of "commits" and "work that could be pushed". I was usually working on one big commit. I appreciate this flexibility in keeping track of "code maturity". The master branch should always be kept working with all tests passing.
But I often want to save code in "less good" states. And it even helps if I'm on a desktop and want to move to a laptop to change locations. I just push to the dev branch and then pull on the laptop, without messing up the master.