Version Control-FAQs

What is a Version Control System (VCS)?

Version Control Systems are a category of software tools that helps in recording changes made to files by keeping a track of modifications done to the code.

What are the version control tools supported by ARM?

The following version controls are supported:

• GIT

• TFS

• SVN

What is GitHub and how does it work?

GitHub is the home for all developers—a platform where you can share code, contribute to open source projects, or even automate your workflow with tools like GitHub Actions and Packages. If you’re just getting started with GitHub, you may know us best as a place for version control and collaboration.

Are Git and GitHub the same?

Git is a version control system (VCS). GitHub is the platform where Git repositories can be hosted and teams can work on them together.

What's the difference between git fetch and git pull?

• git fetch really only downloads new data from a remote repository - but it doesn't integrate any of this new data into your working files. Fetch is great for getting a fresh view on all the things that happened in a remote repository.

• git pull, in contrast, is used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server. This means that pull not only downloads new data; it also directly integrates it into your current working copy files.

Why do Merge Conflicts happen?

When working in Version Control System such as GIT, users can combine commits from two different branches through an action known as merging. Files are automatically merged unless there are conflicting sets of changes (i.e. the commits update the same line of code differently).

A merge conflict is an event that occurs when your version control is unable to automatically resolve differences in code between two commits.

When there are conflicting changes on the same lines, a “merge conflict” occurs because the version control doesn’t know which code to keep and which to discard.

What is Commit in AutoRABIT?

As you work with your files that are under version control, each change is tracked automatically. This can include modifying a file, deleting a directory, adding a new file, moving files or just about anything else that might alter the state of the file. Instead of recording each change individually, the version control system will wait for you to submit your changes as a single collection of actions. In version control, this collection of actions is known as a commit.

Branching and Merging- what's the difference?

A branch allows you to create a copy (or snapshot) of the repository that you can modify in parallel without altering the main set. You can continue to commit new changes to the branch as you work, while others commit to the trunk or master without the changes affecting each other.

Once you’re comfortable with the experimental code, you will want to make it part of the trunk or master again. This is where merging comes in. Since the version control system has recorded every change so far, it knows how each file has been altered. By merging the branch with the trunk or master (or even another branch), your version control tool will attempt to seamlessly merge each file and line of code automatically. Once a branch is merged it then updates the trunk or master with the latest files.

What are Remote repositories?

Remote repositories allow us to share our changes with other members of the team. They can be on a private server, on a different computer than yours, or hosted on a different service. Wherever yours is hosted, you'll need to be able to sync your local repository with the remote repository frequently. To start sharing changes with others, you have to push them to a remote repository. This will cause the remote repository to update and synchronize with your local repository.

Why merge is getting auto-rejected during deployment?

Below are the reasons why ARM rejects your merge request:

• It will be auto-rejected if the proper merge criteria are not enabled. The merge criteria must be enabled before you are performing the jobs.

  • Navigate to Admin > My Account > Merge Setting to select the proper merge criteria. Click Here for a more detailed explanation.

• Workspaces is wrongly configured

  • Search for the workspace id which has the name of the source & target branch and reset that workspace. Once the workspace reset is complete, trigger a new merge.

• Failed to meet the actual code coverage criteria

  • Please update the merge criteria as needed by disabling code coverage under Admin > My Account > Merge Settings.

ARM says, "Local and remote repositories are not on the same revision," what does it mean?"

There are several possible explanations for AutoRABIT to throw an error "local and remote repo is not on same revision":

1. The local repository is out of date.

2. The branch that contains the commit was deleted, so the commit is no longer referenced

3. Someone force pushed over the commit.

How long does it take to register a version control branch in ARM?

The actual registration of a branch depends on the data available in your version control repository. Mostly, the registration can be accomplished in a matter of 1-2 minutes, however, in some rare cases, it can take anywhere from 30 minutes to an hour.

Is it possible with the ARM tool to have merge approval only for one specific branch and not for others?

We don't have a feature to limit approvals to specific branches right now. However, there are a few options that can assist you in obtaining merge approval for a specific branch:

• When performing a merge, make sure none of the options under New EZ Merge > Prevalidation Merge are selected; this allows you to merge without approval.

• Under Admin > MyAccount > Merge Settings, make sure the disable merge self-approval checkbox is not selected.

I can only see the Production org and none of the development instances when I try to do a new EZ commit.

You haven't switched on the skip mapping feature, which is why this is happening. Select "Skip Mappings" from the drop-down menu in My Profile > My Roles.

What is the cause of ARM's inability to initiate the auto build on commit, as well as the failure of a GitHub pull request?

1. Allow pull requests and build on commit in your VC repository.

2. To see the external pull request, switch on ARM's auto-sync option.

Why is ARM rejecting my merge request at the final step?

This is due to the fact that the merge criteria do not match the ARM settings. Before submitting the merge request, configure it in ARM to match your needs. Make the appropriate modifications under Admin > Merge Settings.

All merge deployments in ARM fail when I try to deploy code from one sandbox to another. Could you assist me with this?

You won't be able to deploy the code to the target org if all of the profile objects in the package have access permissions set to "false." It's not an ARM issue; it's a salesforce behavior.

Change the access permission to "True" in all profile objects and deploy to fix the problem; it should now work.

I am getting a space issue with my development team, and they are not able to commit the changes through AutoRABIT, due to this branch creation is getting failed. Why?

• Branch creation seems to fail due to the huge Workspace checkout. I would recommend unregistering the unused branches that are already registered in AutoRABIT so that the base checkout will get deleted and the workspace size will be increased.

• Under Workspaces, there are some workspace IDs where there is Delete button is greyed out and those are the base checkouts it will get deleted only if we unregister those branches. So, ensure if there are any unused branches then proceed with unregistering them in AutoRABIT.

I have access to the apex class for the profiles, but I am not able to find the updated profile data in AutoRABIT.

The Apex class permissions for the profiles can be committed only when you select both Apex classes and profile metadata members while performing EZ-Commit. Also, you need to select the checkbox "Commit Only Profiles for selected metadata members" on the Commits Summary page to commit only profile changes that contain apex class permissions.and

Why does a Git branch not display in the "My version control Mapping list" under "My Profile" after being registered in AutoRABIT?

This is because you haven't given permission to that branch in AutoRABIT yet. Re-register the branch in AutoRABIT by checking the checkboxes next to the GIT lists to whom you want to access in the My Profile section.

Why the Profiles/Permission sets are not getting committed to my development branch during EZ-Commit?

For such a case, there can be three possibilities:

• There are no changes in metadata components between the sandbox and the branch.

• Salesforce is not allowing it

  • Retrieve the permission sets using the workbench. If still the permission sets are not retrieved, then it is a limitation from Salesforce. Request you contact Salesforce Support Team for further assistance.

• Components (StandardField, Report, Dashboard, etc.) related to the Profile/Permission sets are not selected during the commit.

  • Select the appropriate components related to the Profiles/ Permissions object under "Select metadata members" in the New EZ-Commit screen and commit once again.

How to deploy the Field level Security (FLS) permission from version control to your target org?

Field Level Security (FLS) settings will allow you to restrict the users’ access to view and edit specific fields. In order to deploy the FLS settings from a branch to a sandbox in AutoRABIT, you need to perform the below steps:

• During "EZ-Commit"

  • While committing the changes from a sandbox to a destination branch, commit the custom fields and profiles in a single commit.

• During "Deployment"

  • While deploying the Field Level Security (FLS) permissions from the version control branch to the target org, ensure the custom fields and profiles are a part of the same revision.

What is the functional difference between Release Label Merge and Release Label Deployment?

Release Label is a set of commit revisions.

• When you merge using a release label, ARM will cherry-pick all the revisions and labels in that release label and consolidate all the changes made to that branch. These delta changes are pushed to the destination branch after the conflicts (if any) have been resolved.

• Whereas, when you deploy a release label, ARM identifies and uses the latest revision in that Release Label as HEAD. The latest revision is identified based on the commit date. Any files in that revision that may have been modified, added, or deleted are consolidated, including any changes made to those files in other revisions besides the HEAD revision. When the deployment is performed, this consolidated metadata file is retrieved.

While creating a new Release Label, I did not select the 'Create package manifest for Deployment' check box. Can I still create a package?

Yes. If you did not select the check box while creating the release label, you can click on the Create Artifact button on the Release Label Summary Screen to manually create and run the package.

Why can't I click the 'Create Artifact' button on the Release Label Summary screen?

If the Create Artifact button is unavailable to click, the package has been created successfully and can be used for Deployment. It will also be unavailable if package preparation is In-Progress and will be available shortly. You can view the status on the Release Label Summary screen. Create Artifact button will only be available if the package has not been prepared or has failed during preparation.

Why am I getting an error while registering the GitHub repository with SSH?

GitHub no longer allows new RSA keys with SHA-1 signatures. Execute the ssh-keygen -t ed25519 -C “[e-mail]” command in the terminal to create a new key, or contact [e-mail] for further assistance. Please note that you must create the new key in Linux or Unix, not in Windows. For more information, visit https://github.blog/2021-09-01-improving-git-protocol-security-github/

My commit failed with errors like 'Tip of your current branch is behind' and '[rejected] Partial -> Partial (non-fast-forward)'. Why did this happen, and how can I resolve it?

image.png

To put it simply, this was caused because of an expected Git behavior.

Basically, if the commit is rejected with the error message "Tip of your current branch is behind," it means that there is another commit that has already been done on top of the target branch.

Let us assume that you have initiated a merge, and while it is processing, someone else (other developers) performs a commit onto the target branch. This will modify the HEAD revision, and the merge that had set a HEAD revision will no longer be the latest HEAD on the target branch. After resolving the conflicts and while committing the merge, this error is displayed.

This merge process will fail, and it is not possible to Re-Push because when compared to the latest HEAD revision, it should bring up the conflicts again, which is not possible.

You must re-perform the merge so the commit will set up the latest HEAD revision on the destination branch and process further.

How can I get rid of a malformed duplicate file in the merge?

If the Permissionset file you're trying to upload has some malformed structure, please contact our support team so we can validate using XML validator. After resolving it, you can upload the Permissionset file successfully and proceed with the merge.

I performed a commit using two fields and used that same commit to perform a merge. Why is the second field showing differently and picked up by another object?

The merge with the cherry-pick command by GIT gives you results of such Custom Fields while merging to the target branch. The same thing happened when there was a new commit. The merge process followed even before reverting the actual commit and got the same result from GIT. There is no issue with the workspaces here.

I’m trying to create a commit, but the delta fails with the error 'REJECTED_NONFASTFORWARD.'

Suppose the error REJECTED_NONFASTFORWARD is thrown in your EZ-Commit; in that case, the issue is specific to your repository, and the error occurs at the GIT version control level when multiple developers try to modify a file simultaneously. If you reencounter this issue, please wait a few minutes and reattempt the commit.

Why can’t I select the Report Type for deployment?

Please go to Admin->My account-> Salesforce Settings->Included Metadata Types, and check if the Report and Report Type are included in the Salesforce Settings. If these are not included, please include them to see them during the metadata selection for deployment.

Why is the API name change showing under Deleted Components in Commit?

When there is an API name change, Salesforce considers it a new metadata API while the retrieved call occurs. When committing such API name change components, please select the new API name, and the older one can be deleted as a destructive commit. Now, while deploying these changes, we recommend using the Pre-destructive option to deploy the deleted one first, and then the actual API name change components get deployed.

Why can't I see any Salesforce Orgs or Version Control repositories while performing EZ-Commit?

Salesforce Orgs are displayed on the EZ-Commit screen if an admin selects the Skip Mappings checkbox on the Profile page. Profile > My Roles > Skip Mappings

If the admin does not enable Skip Mappings, users must map their respective Version Control repository branch to their Salesforce Org. Admin > Salesforce Org Mgmt > Selected Salesforce Org > Salesforce Org- Mapping, then map the respective branches individually.

To avoid this, contact your admin to select the Skip Mappings checkbox under the My Roles section on the Profile page. More information on how to map a branch to a Salesforce org is available here.

How can I commit restricted 'Profile User Permissions'?

Due to limitations from Salesforce, User Permissions set to False cannot be retrieved via Metadata API call. Hence, those changes are not displayed under the File Diff report in EZ-Commit for Profiles. This is an expected behavior. For more information on the Profile Metadata, click here.

Why are metadata members added to or removed from the package.xml during a commit even if they are not part of the commit?

The metadata members present in the target branch are added to the package.xml, and those absent from the target branch are removed. Verify that the deleted members no longer exist and the added members are listed in the target branch of your version control repository. If the added/deleted metadata members do not match those in the target branch, contact the AutoRABIT support team at [e-mail] for further assistance and troubleshooting.

Why are Wave Components missing from the component list during EZ-Commit despite being listed as 'Included Metadata Types' in the Salesforce settings?

If the user who registered the SF Org in ARM has no Einstein Analytics license, Wave Components do not appear under metadata members in EZ-Commit.

Why did the Merge/Commit Prevalidation deployment fail due to the error 'Picklist not found'?

The potential causes of Picklist not found error-related Merge/Commit Prevalidation deployment failures are listed below, along with the procedures you need to follow to fix them:

• Verify the field name: Verify the API name or the label of the picklist field you're trying to reference and the spelling and capitalization of your source.

• Check the object: Verify the object you're working with has the picklist field you're looking for. Locate the proper object by going to the Object Manager in Salesforce Setup. Look for the disputed field in the Fields & Relationships section in the target org.

• Validate field-level security: Make sure the user or profile you're using can see and access the picklist field. Ensure the user has the appropriate permissions to see and update the field by checking the field-level security settings for their profile. Check the field-level security settings to ensure the user's profile has appropriate permissions to view and edit the field.

• Consider record types: If your Salesforce org utilizes record types, check to see if the picklist field is specific to a particular record type. If it is, ensure that the user or profile you're using has access to the relevant record type.

• Consider field dependencies: If the picklist field has any field dependencies or controlling fields, ensure that the controlling field values are set correctly. If the controlling field values are incorrect or incompatible, it can lead to the "picklist field not found" error.

Why are unexpected files not part of a revision picked in the merge when the revision is cherry-picked?

This is not an ARM issue but rather an expected behavior from Git. Perform the following actions outside of ARM to determine whether the issue stems from ARM or Git:

1. Take a local clone of the repository and then checkout of that branch using the command below: git checkout <branchname>

2. Cherry-pick merge the revision by executing the command in the applying merge log which is as shown below: git cherry-pick < revision > -n --strategy recursive --strategy-option ignore-cr-at-eol

3. Check the results for the modified files by running the command below: git status

Compare the results with the changes in the ARM file. If the results match the changes in the ARM file, we can conclude that this is Git behavior. If the results do not match, contact the AutoRABIT support team at [e-mail] so we can assist you further.