[kosinus]

Or rebase. Don't hide merge fixes in merge commits, keep your changes relevant when read in context of current master.

Unless you're working on a topic branch together with another dev, but I find that rarely happens in practice.

[nogridbag]

Yes I just completed a large refactoring in a feature branch which affected lots of files and the only way to stay sane throughout the process was to constantly rebase my work on top of master (within my feature branch).

Once my refactoring was complete I squashed it into a single commit to prepare to merge (or rebase) into master. I don't really think it's useful to keep the history of how I implemented that refactoring. Squashing it into a single commit is far easier to revert then if I merged multiple commits into master.

[nerdponx]

Even so, if you can both adhere to "pull before you push, and use force-with-lease instead of force" the rebase workflow is possible too. However it's more of an abuse of Git rather than a use of it.

[msvalkon]

I find this to be the optimal wow.