• 25 Nov 2022
  • 9 Minutes to read
  • Contributors
  • Dark


  • Dark

What is an EZ-Merge?

Merging is simply putting a forked history back together again. Say we have a new branch feature based on the master branch. We now want to merge this feature branch into the master. Using the merge process in AutoRABIT will merge the specified branch feature into the current branch...we'll assume the master. 

Before you begin

Before a merge, there are several preparation steps to take to ensure the merge goes smoothly.

  1. Register your Version Control Repository in AutoRABIT: This step can only be performed by an Admin. Register your Version Control Repositories, such as GIT, SVN, or TFS in AutoRABIT. 
  2. Register your Salesforce Organization in AutoRABIT: AutoRABIT connects to your Salesforce Org using either the secure OAuth method or using username/password connections. This step can only be performed by an Admin. 
  3. Set Up a BranchInstead of directly making changes to the code base, you can branch off from the mainline and work on a specific feature in an isolated branch. This step can only be performed by an Admin. 
  4. Mapping the users with the Version Control and Salesforce Orgs in the "My Profile" section: Set up the permissions to create a project in AutoRABIT. 
  5. Fetch the latest remote commits: Make sure the receiving branch and the merging branch are up to date with the latest remote changes.

How do I merge my changes to a branch?

The merge process is generally performed when a feature is ready for user testing in Salesforce Orgs and usually involves code review by other members of the development team.

Important Note:
The merge process in AutoRABIT remains valid for 7 days. Make sure you resolve the merge conflicts (if any) for your merge label and commit the changes to another branch within 7 days or else the merge expires. Even merge-related reports such as Static Code Analysis reports, Deployment Validation reports, or Difference reports generated also expire after 7 days.
  1. Hover your mouse over the Version Control module and select Commits.
  2. Click on the New EZ-Merge button.
    The New EZ-Merge screen is best viewed when the zoom setting is set to 80% on your Chrome/Firefox browser.
  3. In the New EZ-Merge screen, select the version control repository from where the metadata components will be fetched.
  4. Select your source (base) branch and the target branch.
  5. Select the merge type from the dropdown:
    • Entire Branch 
    • Single Revision
    • Commit Label
    • Release Label
    • ALM Label

Merge Type

A. Entire Branch

This option will merge the entire change from one branch to another branch. 

Different options for "Entire Branch" merge type 

  • Delete Source Branch: Once you have successfully merged the changes from the source branch to another branch, you can delete the source branch permanently. To delete the source branch, select the Delete Source Branch checkbox which gets auto-populated whenever Entire Branch as a merge type is selected.

B. Single Revision

Merge a Single Revision from the Commits that you have performed. You can either enter the revision number (in case you remember it) or use the Search () button next to the Single Revision field to pull a list of revisions from which you can choose which revision to use in the deployment.

Get Latest HEAD points out the last commit in the current checkout branch.

There could be a situation where you have entered an incorrect revision number and hit the Search button. In this case, an error message will be shown indicating that the revision number entered is incorrect.

You can also use the 'Get All Revisions' button to try and get all the revisions and check for your revision from the list.

C. Commit Label

Select the Commit Labels created while committing to Version Control System. The commit labels that are either created during EZ-Commit or Merge process will get fetched in the Commit Label field.

For example, Sai-DX-CL2_EZ-Commit, here Sai-DX-CL2 indicates the commit label name and EZ-Commit denotes the label created during the EZ-Commit process.

D. Release Label

Here, you can select the Release Labels created using the committed Revisions as well as the Labels.

  1. Select the Merge Type as Release Label. The Release Labels field is populated with all the available release labels in the particular branch.
  2. From the Release Labels field choose the one you want.

E. ALM Label

This allows you to choose and promote the ALM user stories to a branch either higher or lower.

  1. Select the Merge Type as ALM Label.
  2. The Work Item will gather all the user stories for which the ALM commits happened in the Source Branch of chosen Version Control Repository. Click on the Search () icon to find the list of user stories or work items that were fetched.
    You will not have the option to manually enter the work item details, you need to select the work item from the list fetched.
  3. Select one of the work items from the list fetched, and click OK.

More Options:

  1. Conflict Resolution Strategy: This field allows you to select the way you want to resolve the conflicts. If you and another user change the same file in different sandboxes or on different branches, a conflict arises when you try to commit your modified files. When the conflict occurs, AutoRABIT will use the below resolve method:
    1. Manually resolve conflicts: Resolve the conflicts manually.
    2. Choose the file from the source: Replaces the copy of the file in your workspace with the version that is in the repo, discarding your changes. 
    3. Choose the file from the destination: Accept the file in your workspace, overwriting the version in the repo when you submit the file.
  2. Enter the Merge Label name and comment (if any).
  3. Enter the Email ID(s) to send an email notification of the merge reports.
  4. Create Commit Label: To create a commit label for the merge operation, select this checkbox.
  5. Create a GIT Tag: GIT tags are a simple and effective way to make sure you can keep track of the different versions of your code, and the important quality of Git's version control. GIT Tag operation allows giving meaningful names to a specific version in the repository.
  6. Skips Profile/ Perm. Set Access-Setting Duplicity Check: If you do not want AutoRABIT to list all duplicate entries for your profile/permission sets, please select this checkbox. (Learn More)
  7. Review Artifact: Select this checkbox to see the list of the changed files staged for commit (during merge conflicts). This gives an ability to preview the changes, review them or edit the files before pushing them into your version control. (Learn More)

Prevalidate Merge

In this section, you can assign certain pre-validation merge operations (such as deployment validation with another Salesforce Org, choosing the Apex test class to run, selecting the static code analysis tool, generating difference reports, etc) before merging it to your target branch.

Different Prevalidate Merge Criteria:

  1. Generate Diff Report: Select this option to auto-generate a code difference report on completion of the commit.
  2. Run Static code Analysis: Select this option if you would like to run a static code analysis tool to identify potential software quality issues before the code moves to production. Similar to "Generate Diff Report," this option will also be auto-selected by default if the criteria are set globally (under the My Account > Commit Validation - Approval Settings section).
    • For ApexPMD, Checkmarx, CodeScan, and SonarQube: AutoRABIT allows you to set the criteria for running the SCA tool, whether to run on all supported metadata types from the full source or to run on the newly added components.

      Important Note:
      Whenever a code analysis is triggered, ARM will wait up to hours for a response. If the code analysis is not completed within 5 hours, then ARM will throw a timeout exception error. This is applicable for all SCA tools.
  3. Validate Deployment: Choose a Salesforce org to validate a future deployment. Further, there are different options to choose from:
    1. Run Destructive Changes: Here you can specify whether to run pre or post-destructive changes while carrying out the merge process.
    2.  Ignore Missing Visibility: With this option, differences in visibility settings between the source and destination branch will not cause the merge to fail. AutoRABIT will compare the source and destination branches and keep only the settings that are common between both branches. 
    3. Ignore installed components: When selected, AutoRABIT will scan for the components that are deployed, and if there are any managed package components located in the destination branch, these components will be excluded from the metadata.zip files while the remaining components are deployed. 
    4. Apex Test Level: Choose your Apex Test level to validate your merge.
Points to Remember:
  1. Prevalidate Merge section will be visible only if the Admin has enabled the 'Merge Setting' checkbox under the My Account section. 
  2. Users with the 'Merge Review Overridable' role has special permission to either check or uncheck the pre-validate option. However, each time they try to commit to the branch, a notification alert mail gets triggered to the email ID as specified in My Account > Merge Settings
  3. Prevalidate Merge section will not be displayed for Version control repositories registered in the 'SFDX' structure.
  4. If the meta-XML file does not exist in the Destination Branch and is available in the Source Branch, then the meta-XML file is copied from the Source Branch to the Destination Branch, before committing to the remote repository. The newly added meta-XML file will be added to the files list and will be committed to the remote repository and added to the Validate Deployment package.
  5. Based on the permission assigned by your Admin, you will see the options in the active state. If your Admin has assigned you the permission to run a static code analysis tool only to review your code before merging them, in such a scenario Run Static Code Analysis option will remain in-active state while other options will remain disabled or won't be seen.
  6. Based on the Approval Reviewer level set in 'Merge Settings' (under the My Account section) you need to specify the email address of the reviewers for a given proposed code change and to approve merge requests.

ALM Integration

You can update the status of the ALM work item through the ALM Integration section (below the Pre-validate Merge section) and the same gets reflected in your ALM system.

  1. Select the ALM label.
  2. Select the Project and the sprint for which the commit is planned.
  3. Select the Work Item and the Current Status for the work item gets auto-populated. This allows you to update the ALM for the Merge operation with or without changing the current work item status. Click on the + icon to add another work item and update its status.

Click on either Dry Run or Validate & Merge.

Dry RunValidate & Merge
  • The dry run option will show the user how the merge will execute without making any changes.
  • Don’t actually merge anything, just show what would be done.
  • Lists what will be pushed to the Integration branch from the Dev branch.
  • Status shows as "MERGE NOT COMMITTED."
  • View the conflicts if there are any during the dry run merge. Later, it will ask to initiate a merge in the View Conflict screen, and it gets converted to a standard validation merge.
  • Changes are validated and later merged from the Dev branch to the Integration branch without committing to the remote repository.
  • The difference report and the static code analysis report are published based on the delta and shared with the user.
  • The admin/reviewer can approve or reject the changes.
  • If approved, the user can merge the actual changes to the remote repository.

  • For Entire Branch and Single Revision merge types, a notification appears that the merge request has been submitted. Click OK, and you will be auto-redirected to the Commits screen, where you can find the status of the merge that was initiated.
  • For Release Label, Commit Label, and ALM Label merge types, a confirmation dialog box appears that will ask you to approve the requested operation. Click OK, and you will be auto-redirected to the Commits screen, where you can find the status of the merge that was initiated.


For merge labels that are either in progress or have some conflicts, in such a scenario, you will find a popup that will appear as shown below when you press the Validate & Merge button. These merge conflict statuses will only be shown for the merges created within 7 days.

Merge Labels

Resolution: To prevent this, first, resolve current merge conflicts or allow the in-progress merge status to move to the completed state and then re-start the merge process again.

What's Next