SOURCE VERSION CONTROL WITH GIT, THE SINGLE SOURCE OF TRUTH

A version control system tracks changes over time in a file or a set of files stored in a specific location,
known as a repository. Version control with Git gives you the possibility of cloning the repository locally.
This way, developers can have a copy of all the files in the repository at any time in their local machine.

Important Terms:

Git Commit: It records a change. A commit indicates that the content of a file has been modified.

Git Branch: Commits are organized into branches. A branch collects the versions of the files and the
commit history, which references the changes in these files over time.

Git Merge: A Git merge integrates changes from one branch into another and keeps your branches aligned.

Git Repository: It is the place where file versions, branches and commits are stored. There are two types of
repositories:

Master/Main Branch: This branch contains the production-ready version of your code delivered to your
users.

Release Branch: It is branched off from master and groups the features branches’ changes you have been
working on. After all the developers have integrated their contributions in the release branch, the release
branch is merged and deployed into the master branch.

Feature Branch: It is generated from the release branch. This is the branch where developers apply the
modifications related to the features. Once a developer is done with the changes, the feature branches are
merged into the release branch.
Pull Request: A pull request is essentially an approval process before merging two branches so that the
changes are introduced in a controlled way.

COMMIT PROCESS

In the Copado model, each Salesforce environment is tied to a branch in the repository. In between each
branch representing the different environments, Copado makes use of feature branches and promotion
branches. Let’s see an example:
1. When Dave commits in his user story (1) Copado creates a feature branch (2) that captures all the commits
related to his user story.

By default, feature branches are generated from the main branch of the pipeline, usually master. This is
because Production is considered a stable environment.

After the commit, Copado merges the feature branch (3) into the Org’s Branch (Dev 1) where Dave was
working. This is to keep the Org data in sync with metadata in the org.

2. Before promoting the user story, he creates a pull request from the user story to compare the user story
changes against UAT. The pull request is made between the user story feature branch and the destination
branch to see how his changes will impact the destination Org.

3. Debbie has been working on her user story in Dev2. When she commits in her user story (4) Copado
creates a new feature branch for her from master, keeping her changes separated from Dave’s changes (5).
Following the same approach as Dave’s, Copado merges the feature branch (6) with Org’s Branch (Dev2)
where Debbie had been working.

PROMOTION TO UAT

1. When Dave’s user story is promoted to UAT, a promotion branch is created out of the uat branch(1).
2. During this promotion process, if no conflicts are detected, the feature branch is merged into the
Promotion branch (2). Thus, the original content of UAT remains, while the new contributions from Dev1
are added.

3. If multiple user stories are included in a Promotion record, their respective feature branches will be
merged sequentially into the Promotion branch.

4. Dave executes the Deployment. The source used for the deployment will be the files as they are in the
Promotion Branch at the time of the latest commit.
5. Once the Deployment has been successfully completed (3), the Promotion branch is merged into the uat
branch (4), incorporating the changes committed in the user story into the destination Org branch.

PROMOTION TO PRODUCTION

1. The release manager includes both in a promotion and creates a deployment. As he creates the
Deployment, a promotion branch is created out of the master branch (1).

2. The feature branches are reused and merged into this Promotion branch (2).

3. Let’s imagine that the Business chooses not to move Debbie’s user story in this release. With Copado, the
release manager only needs to deselect Debbie’s user story from the Promotion record and submit a new
deployment. This will create another promotion branch without Debbie’s feature branch.

4. Following a successful deployment (3), the new Promotion branch will get merged into master, and the
user story commits will reach the final stage (4).

GIT MERGE CONFLICT

Git merge conflict arises when developers commit changes to two separate branches but on the same line of
code or file.

Copado encounters disparity between files when:

The feature branch is merged into the source Org’s branch. The feature branch is merged into the Promotion
branch.

COPADO RESOLVES CONFLICT VIA

Auto-Resolve: Copado will apply a different auto-resolve conflict strategy depending upon the file type.
Manual Resolution: Copado will allow users to resolve the conflict manually and enable them to apply a
proper conflict resolution strategy.
Copado has an Auto-Resolve feature that helps you to resolve conflicts in Git automatically. However, you
sometimes come across complex metadata types where resolving the conflict automatically would not be a
perfect solution.

The Online Conflict Resolution feature can be activated in two different places: In your Pipeline record

In your Promotion record

In both the records, you need to exclude the metadata types you want to resolve manually. This can be done
by moving the metadata files to the Chosen column of Exclude From Auto Resolve field.

5 STEPS TO RESOLVE CONFLICT MANUALLY

1. Activate the Online Conflict Resolution feature either from the Pipeline or Promotion record. 2. Select
metadata file types you want to resolve conflicts manually for in the Exclude From Auto

Resolve picklist field.

5. Once the conflict is resolved manually, click on Save.