[tonymet]

git merge doesn't conserve the history it pollutes it. any more than a few merges or a few developers and you are left with an impossible to read merge log with 10+ parallel paths.

Git rebase preserves a linear history . Keep a reflog on the server (github has one built in) for cases where someone has screwed up the history. and secure shared branches to avoid clobbering it.

[riperoni]

Yes, securing branches is very important, much like git-hooks if you are serious about the Git flow.

How do you specifically investigate the history with rebase and 10+ developers? Do you manually look into commits on the branch, or go by a single file history, or look at merge/pull requests?

Personally, I prefer looking at the context of a file change within a merge/pull request. The specific merged/pull request can be read from the merge commits. And in case a specific file history is of interest, I can backtrack from that file's associated commits.

[tonymet]

if master has a clean history, then use git-blame on the file to see where a change was introduced, and git show to see the entire change. then you can walk back through the git log to understand the context of the change.

[seba_dos1]

Merge doesn't pollute the repository. Just like rebase, it's a valid tool to use when what you want to do with your repo structure calls for it. It's the fact that most people use git blindly and end up doing things that don't make sense that pollutes their histories.

There are tons of merge commits in the Linux repository, but no useless ones. Note how in its nature Linux process also does implicit rebasing of applied patches when they land in subtrees.