[gutnor]

Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it.

Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history.

Not quite sure the obsession people have in using only 50% of the tool they have because the other 50% could be misused.

Similarly, digging for a bug in several hundred commits is going to be shit. Hindsight is very deceptive with bug hunting - they always hide in plain sight, if you know where it is, it is easy to imagine "oh, I would have seen it immediately with a merge". Maybe, probably not.

You see that of that kind of overreaction in Management. There is a bug in production, we must introduce more testing, or more testing phase, or change the way we design the around that single experience. But sometimes, bugs just happen.

[keeperofdakeys]

Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details.

I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the latter being commits are features.

[oddlyaromatic]

I'm a pretty basic got user, just wanted to say this was a really useful distinction for me to read.