Commit Changes Overview

Updated 1 week ago by Copado Solutions

If you are not using Copado with Git integration, please refer to the articles User Stories - Add Metadata and User Stories - Add Commits.

The commit process is used in Copado to link changes to a user story and then record these changes in the repository.

It’s really important to know how to properly commit changes because these committed changes will drive the deployments later on in the release process. It is key to commit all that is needed in order to deliver your user story, but not to commit more than necessary.

When committing changes to a user story, the changes are committed into a new user story feature branch that is automatically created by Copado’s backend with the same name of the user story. This will make it easier to identify the branch within your repository.

By default, the user story feature branch is created out of the main branch specified in the Deployment Flow record. However, in some special cases such as when working with releases, the feature branch can be created out of a different branch.

Commit Process

  1. When you create a new commit, you will be prompted to enter a commit message and select the metadata components from a list of items.
    The metadata list comes from the source org that is configured in a Git snapshot.
  2. Copado will create a package.xml on the fly and perform a metadata retrieve of the selected metadata.
  3. Copado will then clone the repository/branch and will update the retrieved changes in the branch.
  4. Finally, Copado will push the changes back to the repository.

Understanding how changes are committed requires a key understanding of how metadata retrieve works and how Copado enhances it. Here are some examples of different metadata retrieve behaviors:

  1. Easy ones: 1:1 (1 metadata component = 1 file in Git).
  • These are the majority of the metadata types, therefore, there is no need to list them all. If a metadata type is not listed in the Danger list or the Special Cases section below, it should be an easy 1:1 type. 
  • Examples of this category are:
    • ApexClass, ApexTrigger, ApexPage, ApexComponent, StaticResource, etc.
    • Report, EmailTemplate.
  1. Danger ones: 1*:1 (1 parent metadata component = 1 file in Git), but it will include many nested components.
  • The best practice is to never commit a danger metadata type (e.g. CustomObject) unless it’s newly created and will be committed for the first time. Once this danger metadata type is committed, you should continue adding nested components to the parent component.
  • Here is a clear example: when a developer or admin creates a new custom object, the user will commit the custom object for the first commit, which will include all the fields and validation rules that the user set up at the moment of the first commit. After this point, the user must commit only the incremental changes, such as new fields, changes in validation rules, list views, fieldsets, etc.

Have this list in mind the next time you commit danger metadata types in Copado:

Special Cases

  • Profile
    • When committing profiles, only user permissions will be included in the profile unless other components are selected as well.
    • To deploy the Field Level Security of a field, for example, you have to select the profile together with the field in the same selection, the same commit. The same applies to tab visibilities, you have to include the CustomTab to get the visibility of that tab. Most typical metadata components update in a profile are CustomObject, CustomField, CustomTab, Layout, RecordType, ApexClass, ApexPage, CustomApplication, CustomPermission, and HomePageLayout.
    • Copado will merge the retrieved permissions into the profile in Git.
    • When committing files, if you select the Retrieve Only checkbox for custom objects, custom fields and page layouts, you will be able to pull OLS/FLS/Layout Assignment without having to commit/deploy the original field/object/layout files. Follow this link to get more information.
  • PermissionSet
    • Permission sets behave in the same way as profiles, only permissions for other selected metadata components will be included.
    • Copado will merge the retrieved permissions into the permission set in Git.
    • You can select the Retrieve Only checkbox for custom objects and custom fields to pull OLS/FLS without having to commit/deploy the original field/object files. Follow this link to get more information.
  • Flow
    • Deploying a Process Builder Flow in Copado is a seamless process.You can deploy a flow that is active in the source org, and the flow will be activated automatically in the destination org. You can commit an active flow to your repository and deploy from the commit. Follow this link to get more information.
  • FlowDefinition
    • The FlowDefinition can only be deployed if the flow already exists in the destination. In order to make a deployment not repeatable, the recommendation is not to include this in the source control system (Git) by adding it to your .gitignore file.

*As of v11, Copado introduced new Git Operations, click here for more information.

Important Notes

  • A feature branch will only be created if the metadata retrieved is different from the repository version.  
  • If a feature branch already exists, and the metadata retrieved is different, the new version will be added to the feature branch. If there are no changes, Git does not produce a commit ID and Copado will show the status No changes.
  • If the feature branch does not exist and the metadata selected to be committed has no changes, the feature branch will not be pushed to your repository, and as a consequence, the branch will not exist in your repository.
  • As part of the Update User Story selections action, Copado upserts some other auxiliary records and fields such as Git commits and metadata types in selections.

For additional information about committing changes, please refer to the article How to Commit Changes.


How did we do?