What's the best merge strategy for PRs?

There's like a default then squash, ff-only.

What’s the best colour?

Randomly sort files, then let them overwrite eachother, zip the code and email it to everyone in the company

To answer that a lot of details must be known.

Read this
https://git-scm.com/book/en/v2

That....
https://w3docs.com/learn-git/...

And finally that:
https://blog.ffwll.ch/2017/08/...

Then ask the question again.

The W3Docs is just for nice overview / reference.

Trial by combat!

@IntrusionCM I was thinking it was something like 80% of teams use ...

And seems from the 2nd link maybe not applicable for my case. Don't see the options it mentions in the Settings screen.

We use BitBucket to host the repo

Unlessthe company have some strict rules its in my opinion dependent on the PR.

@donuts the thing is: merging can be interpretated into different ... Things.

The W3C page is a list of what git merge does. Because sometimes you'll need to get your hands dirty and imho any process you don't know in a workflow is a thing that will melt your face off.

What you're asking (and I knew that) is how the merge workflow should happen.

But I think it's wiser to understand first a lot of the background information that git provides before planning on a workflow.

Git allows a lot of things.

And handling PR's is dependent on a lot of factors.

Eg. for dedicated branches the Gatekeeper Strategy / Branch Updater Strategy handle how merges happen from A to B.

But you need to look a bit deeper to understand that you not just merge commits.

You're doing versioning. You're deciding what has priority - the upstream / feature branches or the target branch.

You're deciding wether history information needs to be intact (ff only)… can be kept with hints (merge) or can be nuked and fucked up beyond comparison (allow forced push).

These decisions play a vital role in stability.