Commit Changes Overview

Updated 1 week ago by Copado Solutions

What Is a Commit?

A commit is a process used in Copado to link changes to a user story and then record these changes in a Git repository. These committed changes will be later deployed to the different environments in your pipeline, therefore, it is very important to commit just right what you need.

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

How Does the Commit Process Work?

When committing changes in 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 for you to identify the branch within your repository. Then, the feature branch is merged into the source environment branch.

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

Commit Process Flow

Simple and Parent Metadata Types

A simple metadata type is a metadata component that represents one file in Git (1:1), such as an ApexClass, an ApexTrigger, an ApexPage or an ApexComponent, for instance. The majority of metadata types fall within this category, so there is no need to list them all. If a metadata type is not included in the parent list or Special Cases section below, it is a simple metadata type.

A parent metadata type is that where a metadata component represents one file in Git (1:1), but that component contains other nested components. Find below a table with all the parent metadata types and their corresponding nested components:

Metadata Types

Nested Components






















Special Cases

  • When you commit a profile, only user permissions are included in the profile unless you select other components 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 visibility, where you have to include the CustomTab to get the visibility of that tab. 
  • The most typical metadata component updates 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, unless you commit a full profile, in which case the file in the feature branch will overwrite the file in the promotion branch.
  • 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. Check out the article User Stories - Git Metadata to get more information.
Permission Set
  • 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, unless you commit a full permission set, in which case the permission set file in the feature branch will overwrite the file in the promotion branch.
  • 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. Check out the article User Stories - Git Metadata to get more information.
Custom Object

In contrast to the standard behavior of the metadata API, when you commit a custom object only the attributes are committed, unless you select other components as well. This applies to new and existing custom objects.

Custom Object Translation

Custom object translations are handled as nested components. Let’s say you want to commit the custom object translation of a field and you just commit that field together with the translation. By doing this, Copado will only update the translation of that field in the destination, and no other field translations will be committed or merged.


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. Check out the article How to Deploy Flows from v44 to get more information.

Flow Definition

A 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.

Important Considerations

  • 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.
  • In the User Story Selections section, Copado upserts some other auxiliary records and fields such as Git commits and metadata types.

See Also

How did we do?