Remove the commit from step 2. We will merge ignoring the failure. Remove the commit from the other, check it passes with the other commit now on main. Merge the other. We will trigger builds for the main branch of affected repositories to check if everything is in order. Steps 5-8 should happen continuously (e.g. one after another but within a short timespan) so that we don't leave a broken main around. It is important to triage that build process and revert if necessary.

We don’t use merge commits.

But in general the guideline is: code should be clean, history should be realistic.

many organizations end up with messy workflows, or overly complex ones.

If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking