Copado Git Operations

Updated 4 months ago by David Venegas

As of v11, the Copado Git Operations enable users to seamlessly manage Salesforce metadata updates in Git. By moving commits into the cloud, we are eliminating the headache of doing git pull / refresh from server to keep your local code, local git repository, the online git version and the Salesforce online code version in sync.  Non-technical users will also find it easier to commit their work into a Git Repository. 

The Git operations are available when committing changes in a Git Snapshot record or in a User Story record linked to a Branch Management Deployment Flow.

Commit Files

Available in Git Snapshot and User Story Commit page.

The Commit Files operation allows you to commit specific metadata components of an Org into a Git Branch. When the Recommit Files operation is selected, a grid appears with the list of metadata components of an Org (this list is retrieved from the Org Credential of the Git Snapshot).

The steps for committing files are as follows:

  1. Click the "Commit Changes" button in a Git Snapshot or User Story page
  2. The Commit Files operation is selected by default
  3. Select files to be committed and enter a commit message
  4. You are able to select nested components, such as Custom Fields or Validation Rules, Copado will retrieve those components and merge them into the container file, e.g. Account.object
  5. You are able to select nested permissions, such as Custom Field + Profile, Copado will retrieve those permissions and merge them into the container profile or permission set, e.g. Admin.profile
For more details about committing files in a User Story, click here.

Recommit Files

Available in User Story Commit page.

When the Recommit Files operation is selected, the metadata grid appears with the previously committed components in the user story (known as the "User Story Selections"). A checkbox "Re-Create Feature Branch" appears in the layout.

    If the "Re-Create Feature Branch" checkbox is not checked, when committing Copado will do the following:

    • Commit the selected metadata components in the existing feature branch
      • If the feature branch is not found (because it was deleted manually in the Git Repository), Copado creates a feature branch automatically

    If the "Re-Create Feature Branch" checkbox is checked, when committing Copado will do the following:

    • Delete the existing feature branch in the Git repository
    • Create a new feature branch
    • Commit the selected metadata components

    Destructive Changes

    Available in Git Snapshot and User Story Commit page.

    When the Destructive Changes operation is selected, the metadata grid appears. An Org Credential lookup field also appears in the layout.

    • If the user selects a different Org Credential in the lookup field, the grid is reloaded with the new Org Credential's metadata items
    • If the user cannot find a metadata item in the grid (because it was already deleted), the user can click the "Add Row" button located at the bottom of the screen. This button adds a new selected row in the grid and the user can type the Metadata API Name of the component and the Metadata Type. The cell's text value of the new row must not be empty nor contain blank spaces
    • When clicking the Commit Changes button:
      • If committing in a user story: the selected component will be deleted in the feature branch and then merged into the Org's branch. 
      • If committing in a Git Snapshot: the metadata will be deleted directly in the main branch
      • Copado will delete the entire file of the selected metadata if there is one. If the selected components are referenced in other components, these references will also be deleted.
      • For example, if a custom object is selected, the changes will be as follows:
        • The custom object file will be deleted
        • The object translation file(s) of the custom object will be deleted
        • The layout file(s) of the custom object will be deleted
        • The workflow file(s) of the custom object will be deleted
        • The Sharing Rule, Matching Rule, Assignment Rule, Auto Response Rule and Escalation Rule file(s) of the custom object will be deleted
        • The trigger file(s) of the custom object will be deleted
        • The object permissions of the custom object in profiles and permission sets will be deleted
        • The field permissions of the custom object's fields in profiles and permission sets will be deleted

    Once the destructive changes commit is finished, in the User Story Selections you will find the deleted components and any other component that was updated in case it was referencing the deleted component. For example, if a custom object is deleted, in the User Story Selections you will find the custom object marked as Git Deletions, and also the object's layout, sharing rules, workflow, triggers and any other object-specific component. Also, Profiles and Permission Sets that reference the object and its fields (as nested components) appear as Git Upserts since the reference to the object (OLS) and its fields (FLS) are removed from the profile and permission set XML files.

    If you want to delete a component in Git and delete it in the target sandboxes, use this functionality with a User Story. If you just want to delete the component in Git, use this functionality with the Snapshot record.

    NOTE: Copado will not delete in the source Org the components deleted with destructive changes actions. They have to be manually deleted. On the other hand, they will be deleted in the target Org by Copado when the user story is deployed.

    Full Profiles & Permission Sets Operation

    When the Full Profiles & Permission Sets operation is selected, the metadata grid appears with the list of profiles and permission sets. When committing profiles and permission sets using this operation, the complete XML file is committed. This means that the committed files contain all the existing references to other components (e.g. object permissions, field permissions, page accesses, class accesses, layout assignments, record type assignments, etc.).

    This option is very useful when the Profile or the Permission Set has to reconcile the existing permissions in Git with the latest changes in Salesforce. There is a complete article about this operation here.


    How did we do?