Oh Shit, Git?

Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.

From memory...

    git merge origin/master
    git reset origin/master
    git commit -am "squash" # might need some extra fixup if your branch has added files

No need to make a temp branch. I know there's probably a more efficient way of doing this, but this is what's stuck in my head.

Hard to understand exactly what your issue is here. Typically when people say "avoid merge commits" they mean they want you to almost always rebase instead of merge. Can you give an example or something?

The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher.

A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened during populating your own branch. There you solve any conflicts and those usually immediately show you what happened in the meantime, making it easier to do so. The latest greatest now sits in your branch.

Then as a plus, you can retest that merge and if necessary, fix the merge.

Optionally you can do a pull request for reviewing. The diff the reviewers see is conflict-less and makes sense, has only your changes.

Then simply merge to master, which should be trivial if you don't wait for long.

I think that people that think merge commits "pollute the logs" are missing key git features such as `--first-parent`. Git is natively a graph. It gets a lot of powers from that. If you don't want to see all the details of the "subway diagram", add `--first-parent` as a default and focus on the higher level. Merge commits help avoid later conflicts by saving how earlier conflicts were solved. Three-way merging in general and many of git's more complex merging strategies all work better if you save the merge commits. Rebasing throws that baby of information out with the bath water. (It's also useful information to have as a developer needing to archeology dive for how a regression happened. With a merge commit you can see the fingerprints of a bad merge or a mistake that wasn't caught in an ugly merge. With a rebase or squash that information is gone, you have no idea where to find the bad or ugly merges, that data is swept under the rug.)

On top of this, integration is an "interesting" step on its own! When trying to diagnose an issue it can be super valuable to be able to understand whether it was broken from the start or broken by the merge. Rebasing throws all of that valuable information away!

Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.

> Merge main into your branch

The same problem GP was trying to avoid is created here, the merge conflict resolution being on the merge commit.