3 ms·
Small "cleanup" changes required after merging a larger change are often very educational. They highlight subtle nuances in the code that were not thought of w
by prirun 3y ago
Small "cleanup" changes required after merging a larger change are often very educational. They highlight subtle nuances in the code that were not thought of when the large change was merged. If the smaller changes were rebased to make one large commit, the edge-case history is also lost.
- jorams 3y agoI completely agree, which is why I'm not a fan of squash merges that remove such nuance. In practice a feature branch often ends up with roughly three sets of changes: 1. Some small commits in preparation for the bigger change, that are also desirable should the rest never end up being merged 2. The big set of changes, either in one big commit or in a handful of smaller, independent commits 3. Some (usually smaller) commits that reflect nuances thought of or discovered after the biggest batch of changes was made Most of my history cleanup serves to separate part 1 and 2 and to turn part 2 into a set of coherent steps. Depending on how things go each of these might be merged independently or all at once.