My repository has two protected branches: staging and master. And as the name suggests, staging goes to Stage and master goes to Production. Only staging can be merged to master, no other branch should be.
Both the branches are protected and can only be merged into with valid approvals.
We had enabled only Squash and Merge in the repo. Merging feature branches in staging is all good, and squash works perfect for us. But after testing on Stage once we want to merge into master, doing a squash make things complicated. Now staging and master has a commit each that the other doesn't. What is the best practice around this use case?
Taking a branch out of staging, merging master into it and pushing it to staging doesn't help because the commit on master (lets say A) still doesn't go into staging as A (but as B, a separate squashed commit). Leads to conflicts.
Squash into staging and merge-commit from staging into master works, but there's no way to restrict people to use squash into staging in that way, and people hardly check on what they chose while merging.
My need is to have two protected branches. I want squash on my staging, but there isn't an option to disable/enable that on selective branches on Github.
The GitLab squash and merge strategy makes sense when merging on staging, but it does not seem useful on master.
I would use the "Encourage" option at the project level: Squashing is allowed and selected by default, but can be disabled.
Since people hardly check on what they chose while merging, they will use the default ("squasing").
And the few authorized to merge to master will be more conscious of this option, and disable it when merging to the main branch.