I'm in a bit of a conundrum regarding "foxtrot merges" and Bitbucket. I've referenced these answers/articles for background:
In the project I'm working on, the repo on Bitbucket has:
Control Freak preventing Foxtrot Merges
Merges to the main branch limited to via Pull Request only
If the main branch advances to some point while I'm working on my feature x branch, what is the best way to resolve this to facilitate the PR to get it checked in? I think the only solution is to rebase it. Is that correct?
For clarity, say I've got something like this:
A -- B -- C -- D -- E -- F <main>
\
\-- G -- H -- I <feature x>
At this point, I want to merge my feature back to main and I must to that via PR, but if there is a conflict, I cannot submit the PR as the conflict must be resolved (I cannot merge and resolve the conflict manually because of the PR requirements).
But, I cannot pull or merge main back into my feature x even thought that would resolve the conflicts because then the subsequent push of that back up to the origin will be rejected as a foxtrot merge.
Rebase of feature x works, but is sometimes a bit more of a pain. Is there another option? Or is rebase the right answer for other reasons? Is there a "no-fast-forward option" here that I'm missing?
The systematic "solution" to prevent foxtrot merges is git merge --no-ff.
I don't know how this translates in bitbucket GUI, perhaps a checkbox with "prevent fast forward merges".
If you have such an option activated, any way to solve your merge conflict will do.
As far as "keeping your history readable" goes, however, my personal taste and experience drive me to favor a rebase workflow.
On that point, you should choose the thing that best works for your team and process.