I know merges can have lots of "pointless" merge requests, so could potentially look messy when compared with the "prettier" version of the commit graph created by rebasing. But is that the only reason one would rebase, to just make it look prettier?
I personally always merge (without squashing) or fast-forward. It's safe, easy and traceable.
Merging does 'pollute' the history with its traceability, but it hasn't bothered me. (The main thing I use history for is git blame, I rarely just read the log or view merge graphs).
Or maybe I just like getting more green squares on my Github page. Merge commits count as a contribution :-)
I rebase up and merge down.
A lot of it has to do with how i prefer the git graph. So if I can i do a fast forward merge as well for a clean history.
Both are important in different situations. Here is a nice little overview when to use which in order to keep the history clean :) Also, I found this article quite useful to understand other aspects of rebasing.
All git commands are useful tools. As always, it's just about how you use them!
I use both this way:
If I were more comfident with git, I think the only thing I'd do with rebase too is when I need to get back things from master or develop to a feature, so that it doesn't pollute the history of my feature branches
Does that make sense for the others here?
I make some bits of the web.
Ben Buchanan (200ok)
Not a fan of rebase, particularly when habitually combined with squashing commits (the two seem to always go together).
The benefits of a "clean" history don't outweigh constructing a weird false history. With rebase the pull request I raise today might say I wrote the code, say, three days ago. It erases the history of updates being merged from master, even when those updates were significant to the final change set. Plus it encourages really poor commit messages (because they'll be squashed) and over use of force push (which silences useful errors).
It's also a pain during pull requests. If you rebase as you go, reviewers can't see deltas; if you rebase at the end you are letting authors merge unreviewed code (in other words, relying on people to literally never make a mistake), or you're making reviewers review everything twice.
All for what? Avoiding some merge commits that are incredibly easy to identify? The value is weak and the risk is high.
About the only time a rebase+squash is useful is if you have an excessive amount of commits in a branch, and you want to tidy it up before review. That makes sense. But otherwise, meh. Merge works fine and doesn't create low-value busywork.