Copado Git Operations
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.
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:
- Click the "Commit Changes" button in a Git Snapshot or User Story page
- The Commit Files operation is selected by default
- Select files to be committed and enter a commit message
- 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
- 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
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
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, 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 metadata will be deleted in the feature branch and then merged into the main 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.
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.