The following document highlights how to revert a merge using git commands and the Source Control UI, ensuring it reflects throughout your pipeline and orgs.
Example flow:
Make a new feature branch from your developer sandbox, and then start making changes as usual to head through pipelines. In the example below, we added a new custom field to the Lead object and pushed that into the branch
feature/LeadSecondaryPhoneusing Gearset’s pipelines feature (more information here).Pipelines can then be used to open Pull Requests (PRs) to the next environments, which in this case were Dev1Sync > Integration > UAT, to simulate that feature promoting through as normal.
Once the feature is promoted fully into the UAT org, you can see the
Secondary Phone Numberfield appear in the UAT Org’s Salesforce UI as expected, showing the CI Jobs are taking the feature forward and into orgs as expected.Production then receives a promotion request as expected for the new feature. However, during UAT testing we find that we actually no longer need that feature at all, and make the decision to revert everything back out. This could be due to a number of reasons (superseded by other features, change in direction/scope, or simply wanting to fully back it out to start again). To start this process, we close the Pull Request opened against Production (as we don’t want to send the change there unnecessarily) before beginning the revert process.
Now we dive into our IDE (Visual Studio Code here), open up the right repository and get on the right feature branch (which is
feature/LeadSecondaryPhonein this case), to locate the change we’re looking to revert. This will likely already be downloaded if development work has been undertaken before, but if not please utilizegit cloneandgit checkout(noted here and here) to get to this step.Git commands can then be used in the terminal to back the change out (revert) and push it back to the feature branch.
Using
git logwe can find out the various commits that have occurred in this branch. In this example it’s only 1 (the other 2 below are merges from previous back propagations), but this could be several depending on the complexity/size of the changes in your feature.Using the findings from
git log, we can then find out the unique commit ID (ending ‘866a’ in this example).We then use the command
git revert <commitID>to actually back the changes out, and modify the commit message from the default in the editor (if we don't want to edit the default, pop in--no-editand it will skip that modification step).If dealing with more than 1 commit, see the git revert command line reference here for details to revert multiple commits (usually looking something like
git revert HEAD~5..HEAD~2’to hoover up everything in-between 2 points in time commit-wise).
Once happy, since
git reverthas already taken care of the new commit for us, we can simplygit pushto get that reversion into the feature branch in source control.
We can now head to source control (GitHub in this instance), and see the feature branch compared with the final environment we originally merged it to, which is UAT in this case. GitHub shows us we have 1 commit difference and that’s effectively the deletion.
We then create a pull request directly from GitHub (using the
Create pull requestbutton offered), which lets Gearset kickoff the usual behavior in CI Jobs; it picks up a new PR, closes the original feature PR, and opens us up ags-pipelinepromotion PR, which will then appear in the pipelines UI.Now we can go back to the pipelines view and see a new PR opened against UAT containing the revert. We can then go ahead and
promote changesinto that environment to effectively delete the feature from the org (please ensuredeleted itemsis ticked on the relevant CI Jobs before continuing with this step).Now depending on our
create back propagation pull requestsetting within the pipeline settings (referenced here), the following steps will need to occur:Adjacent environments - we will immediately get the back propagation PRs open up to environments upstream, which we can then go ahead and start merging in to remove the feature from orgs it has already passed through (in my example that would be
IntegrationandDev1 SandboxFinal environment - we would get a PR open up again to the next environment along (in this example that’s our final one, Production), ready to finish the flow. This is the flow the rest of the example will follow.
We can see from the above screenshot that the only 2 commits involved are the initial change, and then a reversion. We can safely promote this 'change’ into the final environment (since it’s effectively 'nothing changes') in order to force the pipeline to recognize a merged change and then back propagate to the other environments. Note - if you don’t want to merge into your final environment to kick off automatic PRs for back propagation, you would need to look at manually raising the PR against each upstream environment and handling them individually.
After that change has finished promoting into the final environment, we can then see the rest of the back propagations open up to environments already passed through. Click on the relevant PR and ‘promote changes’ as normal to revert the feature from those orgs (in this case, deleting that added field from the Lead object)
Once they’ve all completed, you can use the
Recent promotion historytab on the environments to see exactly what's been reverted, and then verify inside the org itself that the change has been reverted as expected.
Following the steps above you can see how reverting features involves elements in the Gearset pipelines UI, an IDE such as Visual Studio Code, git commands, and your Version Control System UI also to bring everything together.
For alternative rollback options, please refer to this article.