I pretty much always just make garbage commits like “wip” before I go home and then eventually rebase them into a single commit for the feature. Not that interested in telling a story of how that given feature was built.
This is exactly what I do, although I will try to split work into multiple commits when it makes sense to do that. I try to plan my work so that I do things linearly, although it doesn’t always work out so nicely.
I see a clean history as less valuable than granular bisection. So I commit whenever it builds, don’t worry too much about the commit messages, and use PRs as the unit of planned change.
I’ve been putting more info into commits lately mainly because I have not been at an organization that imports PRs to whatever their next platform is, which means a lot of interesting information disappears when that system is sunset. On top of that, many systems make it hard to know what commit a PR was part of, which has made debugging difficult if it wasn’t code I was involved in. Or I just don’t know how to track a commit to a PR.
I think the general approach should be “plan your work” but besides the planning one should also remember to clean up commits (e.g. using interactive rebase before pushing).
I use
git add --patchwhen I have a lot of distinct changes to commit. That way git walks you through all changes so you can choose which to stage.Here’s a great overview of git add –patch and –interactive
[Comment removed by author]
All team members review every change? How many team members do you have?
[Comment removed by author]
Fair enough! I imagine that would become untenable with even a few more team members.
My team leaves the option for everyone to review, but requires 2-3 depending on the situation.
I pretty much always just make garbage commits like “wip” before I go home and then eventually rebase them into a single commit for the feature. Not that interested in telling a story of how that given feature was built.
This is exactly what I do, although I will try to split work into multiple commits when it makes sense to do that. I try to plan my work so that I do things linearly, although it doesn’t always work out so nicely.
I see a clean history as less valuable than granular bisection. So I commit whenever it builds, don’t worry too much about the commit messages, and use PRs as the unit of planned change.
I’ve been putting more info into commits lately mainly because I have not been at an organization that imports PRs to whatever their next platform is, which means a lot of interesting information disappears when that system is sunset. On top of that, many systems make it hard to know what commit a PR was part of, which has made debugging difficult if it wasn’t code I was involved in. Or I just don’t know how to track a commit to a PR.
I think the general approach should be “plan your work” but besides the planning one should also remember to clean up commits (e.g. using interactive rebase before pushing).