I like how straightforward this blog post is. The graphics are very helpful in getting the point across. Unfortunately, this is dangerous advice in a reasonabl

I like how straightforward this blog post is. The graphics are very helpful in getting the point across. Unfortunately, this is dangerous advice in a reasonably sized engineering team. The assumption of pushing to master is kind of a dangerous one. Don't do that unless it's a project that is yours and yours alone. If you have a change you want to get in, consider a pull request. Even if you don't need it reviewed, it generally encourages you to use a separate branch. If you find that you have a conflict with origin/master, you can then easily rebase your changes. Because of the nature of refs in git, you can also create a separate branch before rebasing so that you don't have to worry about about losing anything, or just to diff what you ended up changing after a particularly hairy rebase. So yes in short, you can use rebases to avoid merge commits. But the use case here and the workflow described is not one I would recommend for teams using a centralized origin or a stable head of master.