> it also means the feature being worked on is becoming too big/too much in conflict to be kept alive separate for long
That's a really great point and something a colleague pointed out to me when I was musing about this.
Another coworker told me they like to do commits + occasional merges from upstream into their feature branch as normal, then when they have built up a lot of commits, use `git reset --soft master` and then git add/commit all changes as one commit, with a nice verbose commit message.
I really like that approach, if you have to do it.
Your colleague’s approach is nice. The only warning would b e on losing meaningful grouping of work.
For instance if you are doing a change in two clear steps (e.g creating a new module first, and switching existing behaviors to the new module in a second time), having separate commits helps for readability, but also if you end up needing to split your branches in two or more.
In particular it makes a big difference if you happen to need to revert: you’ll probably get away with reverting one of the commits, instead of the whole feature.
That's a really great point and something a colleague pointed out to me when I was musing about this.
Another coworker told me they like to do commits + occasional merges from upstream into their feature branch as normal, then when they have built up a lot of commits, use `git reset --soft master` and then git add/commit all changes as one commit, with a nice verbose commit message.
I really like that approach, if you have to do it.