4 ms·
> If you do need to back out a feature, how would you do it on a rebased, fast-forward merge? I've never been on a team where we fast-forward-merged multiple c
by nthj 11y ago
> If you do need to back out a feature, how would you do it on a rebased, fast-forward merge?
I've never been on a team where we fast-forward-merged multiple commits as a feature. (I'm sure it happens, but I can't see it working well.) What I have seen is fast-forward-merging a single commit (which is equivalent to a cherry-pick, at that point), after using git rebase to squash the feature branch into one single atomic commit and rebasing that commit against master in preparation for mainlining.
Then, you'll never have merge conflicts (if you do, you didn't rebase against master properly prior to the merge), and if we need to revert a feature, the feature lives in master as a single commit.
- 0x0 11y agoSquashing a large feature branch for rebase has a downside that it loses some history and timeline context; if for example an api changed slightly in master in between branch development and branch squash, it can be very confusing trying to understand why the commit did XYZ thing looking at the squashed diff - while if you keep the branch through a merge, it's easy to see that XYZ was written with the older API in mind.
- Osiris 11y agoThis is exactly why I prefer merge commits, so you can see how the development of the feature occurred and if there's a bug where/when/how it was introduced. I don't like erasing development history for the sake of a "clean" or "linear" history.