Click Deploy from Git: How to Deploy Salesforce Changes from a Branch

TL;DR: A click deploy from Git uses a repository branch, not a sandbox, as the source of a point-and-click Salesforce deployment. Tools typically offer four modes: selected components, the whole branch, the differences between two branches, or everything committed since the last successful build. For team releases, deploy branch differences, validate first, and route deletions through a pull request.

What is a click deploy from Git?

A classic click deploy compares two orgs and ships the components you tick, as we explain in how ClickDeploy works and what it costs. A Git-based click deploy keeps the same UI but swaps the source: the tool reads metadata from a branch in a repository such as GitHub, GitLab, Bitbucket or Azure DevOps and deploys it to the target org. You still click. The difference is that every change was committed before it shipped.

Why deploy from a branch instead of an org?

• A shared history. Org-to-org deploys keep no record of who changed what, so a second deploy can silently overwrite the first. A branch keeps every change and its author.
• Review before release. Changes can pass a pull request before they reach any org.
• A known source of truth. The branch mapped to production shows what production should contain, which is what makes a rollback dependable.

Expect some noise. Gearset's documentation notes that orgs keep changing through automated jobs, platform upgrades and user activity, that the Metadata API reorders XML for some component types, and that profile metadata depends on what else is retrieved with it. It recommends tracking frequently changed, high-impact metadata types rather than everything.

What are the Git source options for a click deploy?

Copado Essentials, the tool formerly called ClickDeploy, documents four Git source options, and they map well onto other tools:

1. Selected components from a branch. Works like an org-to-org deploy: you pick components from the branch by hand. It suits a targeted hotfix.
2. Everything in a branch. Deploys the full branch contents in one go. It suits a fresh or rebuilt environment; against production it ships far more than the change.
3. Differences between two branches. Compares a source branch with a comparison branch and deploys only what differs. Copado advises that the comparison branch be the one associated with the target org.
4. Incremental build. A CI job deploys only files committed since the last successful build, tracked by a build marker that advances after each successful deployment. A successful validate-only CI job does not move the marker.

Option three is the Git-native form of delta deployments, and it is the right default for promoting a feature from one environment branch to the next.

How do you click deploy from a Git branch, step by step?

1. Connect the repository and the target org. Authorise both in your tool and keep the repository in one metadata format. Gearset notes that Metadata API format and DX format repositories are structured differently.
2. Map branches to environments. Decide which branch represents each org, for example one for UAT and main for production. Branch comparisons are only as good as this mapping.
3. Choose the source and comparison branches. Pick the feature or release branch as the source and the branch mapped to the target org as the comparison.
4. Review the diff. Read what the tool plans to deploy. If expected metadata is missing, look for a package.xml: Gearset filters comparisons by a valid one by default.
5. Handle deletions deliberately. In Copado Essentials, marking components for deletion in a Git flow removes them from the branch first, so you commit the change and merge it by pull request before the org changes.
6. Validate, then deploy. Run a check-only validation with a chosen Apex test level, then deploy. Our click deploy checklist covers test levels and quick deploy.
7. Merge back. After a successful deploy, merge the source into the comparison branch so the branch matches the org again.

Which tools support click deploys from Git, and what do they cost?

• Copado Essentials: Git integration with GitHub, Bitbucket, GitLab and Azure DevOps sits in Essentials Plus, at $249 per user per month billed annually or $289 monthly, with a 21-day trial, according to its pricing page. The Free and Basic tiers do not list Git integration.
• Gearset: its Compare and deploy page accepts a source control branch as either the source or the target, per its help centre.
• DevOps Center: Salesforce's native, point-and-click and Git-backed option. Salesforce Ben reports that the next-generation version has run natively in production orgs since Spring '26, supports GitHub and Bitbucket, and exposes its operations through the official Salesforce MCP server.
• The CLI route: teams comfortable with a terminal use the community plugin sfdx-git-delta, whose sf sgd source delta command builds a package.xml and a destructiveChanges.xml from two commits. Its maintainers state it is not an officially supported Salesforce tool.

Per-user pricing adds up fast once Git enters the picture: five people on Essentials Plus come to $1,245 a month on annual billing.

How does Tekunda handle Git-based click deploys?

Tekunda is the Salesforce consulting and product company behind Serpent, the DevOps platform it also runs on its own client delivery. In Serpent, admins keep clicking: they pick changes in a UI, attach them to a ticket and promote them through the pipeline, while Git commits, pull requests and Apex tests run underneath. We walk through that flow in DevOps for admins without touching Git. Serpent prices per company rather than per user, so compare it with per-seat tools on our pricing page, and teams leaving Copado Essentials can follow the migration path. More how-tos live in the SF Guides library.

FAQ

Can I click deploy from GitHub to Salesforce without the CLI?

Yes. Copado Essentials Plus, Gearset and DevOps Center all deploy from a Git branch through a point-and-click UI.

What is the difference between a branch deploy and a delta deploy?

A branch deploy ships everything in the branch. A delta deploy ships only what differs between two branches or commits.

Does a Git click deploy delete metadata?

Only when you ask it to. Deletions travel as destructive changes, and in Copado Essentials they are committed and merged by pull request first.

Why does my branch differ from my org right after setup?

Orgs keep changing, and the Metadata API can reorder XML or return different profile content, so some drift is normal.