4 ms·
Rebasing is not the problem, squashing is[1]. I never understood that. To me, it suggests the person does not understand branch merges. You should either: A. R
by rue 17y ago
Rebasing is not the problem, squashing is[1]. I never understood that. To me, it suggests the person does not understand branch merges. You should either:
A. Rebase on top of master, keeping all commits; or
B. Merge the branch, keeping branch history.
[1] Obviously squashing has good uses, too, within the branch. Maybe you want to squash together all commits for a particular feature's implementation (while still keeping the specs for same in a separate commit, hopefully).
- mnemonik 17y agoI have found squashing useful for merging a bug fix branch. Half of a bug fix does nobody any good.
- rue 17y agoYou could squash parts of a single bugfix, sure, if you end up with multiple commits. Still, though, I would leave the spec you wrote (you write tests or specs for bugs you find, right? Right?:) in a separate commit - in case you for example need to revert the fix at some point, or someone else just wants to cherry-pick the spec.
- santry 17y agoThough not explicitly written in the article, it seemed to me that JJ was recommending this approach for dealing with short-lived 'topic' branches like bug fixes and small features. At least, that was the nature of each example branch he gave. I agree with you that if you have a longer-lived branch that's shared among repositories, you'll want to see that merge in the history and optionally squash some of the commits as needed. For short lived topic branches, I often like to squash down to a single commit.