Both. Merge to master, rebase feature branches to keep them up to date with master. Interactive rebase (git rebase -i) before a push is gold too.

I usually have a master branch, feature branches and version branches. Whenever I want to add commits from another branch to master or to a feature branch, I use merge, so that I can always understand what changes happened. However, once I think the whole thing is stable enough for a release, I rebase master (or a fix-branch) into the according version branches. That way, the history in the version branches is not so cluttered and I can see when I added what without the specifics.

Of the two I like rebase.

Though the end result is practically the same, their application is very different.

A rebase actually rewrites history. Commits will get different commit hashes. When working on a local branch this is no problem. That is when I prefer a rebase. On a remote branch however, working with others on the same feature, it is a different story. There is a real danger of rewriting commits others are using. When they update it will seem as if they rebased commits have just vanished.

Though such situations are fixable, they are confusing, costly and I prefer to avoid them altogether. A git merge is the far better option in that case.

So, rebase if working on a local branch, merge if not.

see: code.tutsplus.com/tutorials/rewriting-history-wit…

There's no more, they both have different use cases :-)

• Rebase changes to master into a feature branch.
• Merge feature branches into master.

That's it ;-)

Rebase, because of the sheer amount of flexibility it gives.