[sangnoir]

I'm also very surprised - I thought it was standard to merge master (target upstream branch) into the topic branch frequently (daily seems reasonable). I know some people do not appreciate "merged <branch> into <other branch>" commits in their history, but that is a small price to pay IMO.

[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.

[roblabla]

Well, I routinely `git rebase upstream/master` to keep my git history clean. It has the same effect as a merge from master, but keeps everything tidy.

[draw_down]

Whenever I do this I inevitably end up with merge conflicts in stuff I absolutely didn't touch. I don't know if it's because it's a monorepo with lots of people committing, or what, but it basically never works cleanly. It's very frustrating, particularly because merging master works without a hitch. So I just do that instead.

[emodendroket]

And also will make a huge mess if someone else has checked out your code already.

[mbrock]

Is it really such a huge mess? They'll get a conflict if they try to pull, and then they simply have to rebase their changes onto your new rebased branch, right?

[emodendroket]

I don't put that much faith in everybody else to figure it out themselves.

[user5994461]

It's part of the git workflows.

Everybody merge OR every rebase. The organization gotta decide on the workflow.

[draw_down]

It's a very small price to pay! I can't believe how many people hate this practice because of the merge commits. It's extremely useful and not doing it makes git usage that much worse.