History is only "cleaner" because Git in its default configuration only throws the raw version graph at you and fails to visualize it in a readable fashion. With a properly structured visualization, such as Bazaar's hierarchical logs, merging is not just as clean, it actually carries more information.
In hierarchical logs, a merge commit stands for the series of commits that are being merged. You can then unfold such commits and view the series of commits as a nested list of commits (which may again contain merge commits).
Think of a merge commit as the equivalent of a procedure call where the procedure body is the series of commits being merged.
(Note that there are other ways to visualize version graphs with merge commits; this is just the simplest way to do it and could actually be easily added on top of Git.)
Rebasing has two problems. It discards the original version structure and it can create commits that never build or don't pass tests (because they never existed as such).
Frequent use of rebasing is almost always an indication that a VCS is lacking important functionality.
Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS.
Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).
zegl|8 years ago
rbehrends|8 years ago
In hierarchical logs, a merge commit stands for the series of commits that are being merged. You can then unfold such commits and view the series of commits as a nested list of commits (which may again contain merge commits).
Think of a merge commit as the equivalent of a procedure call where the procedure body is the series of commits being merged.
(Note that there are other ways to visualize version graphs with merge commits; this is just the simplest way to do it and could actually be easily added on top of Git.)
Rebasing has two problems. It discards the original version structure and it can create commits that never build or don't pass tests (because they never existed as such).
Frequent use of rebasing is almost always an indication that a VCS is lacking important functionality.
saltedmd5|8 years ago
Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).