Re:Git Tricks: Avoiding merge when dealing with remote confl...
by harg on Tuesday October 22, 2019 @04:35AM
(#21321418)
I didn't get the impression the article assumed pushing to master. It was more a case of you're working on a feature branch and another dev pushes to that same feature branch before you push your local commits.
I agree that even in larger teams you shouldn't face this problem in the first place if devs work just on their own branches instead of sharing. Rebasing is also a great way way to avoid merge commits.
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.