1

I have a scenario where I will sometimes need to cherry-pick some commits from our UAT branch into our MASTER branch. This is because the business sometimes will request that only specific "features" are moved from UAT to production. I need to be able to pick certain commits to move forward as PR.

The issue I am having is that when try to cherry pick from one the commits (from the UAT branch) to master, Azure DevOps give me the error...

"Encountered conflicts when cherry-picking commit "42af19". This operation needs to be performed locally."

Screen Shot

I am able to do this same pattern against my UAT, QA and Integration branches, I only have this issue against our master branch. I don't have any conflicts in the source branch so I don't believe its that. I also don't have any special rules for the master branch that should keep me from doing a UI based cherry-pick.

I really can't have our developers do this locally so I am hoping for some sort of option where they can use the UI for this.

We are using ADO to host the repo for our Salesforce code. We use another system that handles the CICD pipeline.

The high-level background for this is that we have may have 2 or more PR's that have been promoted and deployed to UAT, but the business may request that we only deploy certain ones. So some PR's might remain open against master for a few dev cycles. The issue is when other PR's move through and we need to promote them from UAT to master, ALL of the changes are getting added to the UAT > MASTER PR due to the fact that the code in the PR's that are in the holding pattern have not been committed to master, so the subsequent PR's would pick up those changes and try to merge them in, and we don't want that.

The thought is that we could cherry-pick commits from UAT as a PR. These only only contain the files we actually want to deploy, not EVERYTHING.

Hopefully someone can help me out with this scenario as I am a little stuck.

Thank you all very much for your guidance!

Eric Elliston
  • 65
  • 1
  • 8
  • Your entire branching strategy sounds like an anti-pattern. Branch-per-environment is an ancient approach to source control that you typically saw in centralized version control systems like TFVC and SVN. Don't cherry-pick changes, use feature toggles to isolate and disable features that are not ready to be visible to end-users. – Daniel Mann Jun 20 '22 at 21:35
  • Well, our developers start each in their own "feature" branch. From there, each raise their own PR's against integration. From there, each environment branch (integration to prod) builds to its own salesforce instance. Our desire was to use feature toggles, but in a code/configuration type of platform like SF, you really can't do that due to all the dependencies. If this was a .net application or java app, of course we would be using feature flags...but in this world its a no-go. – Eric Elliston Jun 21 '22 at 13:42

1 Answers1

1

I have been working with a similar branching strategy for Salesforce. Normally in this situation, we would do the following:

  1. Create a branch out of master - it will be used only to resolve conflict.
    • git checkout -b gs-pipeline/...
  2. Cherry-pick a commit there, you can space separate them if there are many
    • git cherry-pick COMMIT-HASH1 OPTIONAL-COMMIT-HASH2
  3. Solve Conflicts manually, save files, stage them, commit and push
  4. Open Pull Request from gs-pipeline/... -> master

Unfortunately, there is no easy way to solve this within UI as far as I am concerned.

However, when you would down merge from master -> uat(directly or via a separate branch) that may solve your issue. It should be safe as things on master/PRD should already be on UAT and all lower environments.

Maciej Ptak
  • 13
  • 4