You might not want to squash everything into one commit before merging, you can still have multiple commits in one (fast-forward) merge, as long as each of them is in a good state. This is made relatively easy by using the `--autosquash` feature of `git rebase`.
One issue I've seen a few times is that some commit in the middle of a topic branch is the problem, but if you didn't rebase it then that commit itself would look fine on top of the topic branch's parent. However, after merging it's now also on top of other commits, and the interaction with those was the problem. That makes it very hard to find such a problem. Rebasing the history of the topic branch before merging will make finding it much easier.
Ah, I wasn't trying to say those were the only two options, or that either was what you were suggesting. I also typically prefer other things.
I just find that "always squash the entire branch" is a common reaction to "history is messy" and I wanted to surface that (per my understanding) it doesn't actually improve the situation (vis-a-vis bisect in particular, assuming you're passing the correct arguments for your situation) over merging (no-ff, I neglected to specify...) branches where some of the commits do not build.
Comments
You might not want to squash everything into one commit before merging, you can still have multiple commits in one (fast-forward) merge, as long as each of them is in a good state. This is made relatively easy by using the `--autosquash` feature of `git rebase`.
One issue I've seen a few times is that some commit in the middle of a topic branch is the problem, but if you didn't rebase it then that commit itself would look fine on top of the topic branch's parent. However, after merging it's now also on top of other commits, and the interaction with those was the problem. That makes it very hard to find such a problem. Rebasing the history of the topic branch before merging will make finding it much easier.
Ah, I wasn't trying to say those were the only two options, or that either was what you were suggesting. I also typically prefer other things.
I just find that "always squash the entire branch" is a common reaction to "history is messy" and I wanted to surface that (per my understanding) it doesn't actually improve the situation (vis-a-vis bisect in particular, assuming you're passing the correct arguments for your situation) over merging (no-ff, I neglected to specify...) branches where some of the commits do not build.