By deploying SFDX changes in Git, developers can maintain a centralized repository for their source code, enabling version control, collaboration, and history tracking.
It allows developers to track and manage changes across multiple branches, collaborate with teammates, review and merge changes quickly, and maintain a consistent and auditable deployment process.
By leveraging Git, SFDX changes become part of a structured development workflow, enhancing code management.
But it does come with some obstacles, including the following:
If you have multiple orgs, you will have to prepare the deployment yourself. You can do it with tools or manually. You prepare a zip file with the metadata files and manifests. That is the list of components you want to deploy (the “package.xml”).
You would include a “destructiveChanges.xml” if you want to delete something in a particular org.
You could do a full deployment, which is slow and only works for smaller orgs.
Since SFDX projects often include large metadata files, this can lead to larger repository sizes and longer clone and pull times.
When it comes to Git, most people perform incremental deployments based on Git branches. Git commits typically operate at the file level, but Salesforce metadata is structured in a granular manner, consisting of multiple files for a single component.
This can make creating atomic commits that encompass all related changes to a particular Salesforce component difficult.
Git may not be inherently designed to handle Salesforce metadata changes efficiently, resulting in potential conflicts.
This can include passwords or access tokens to the Git repository.
Moreover, using Git effectively requires familiarity with its concepts and commands.
But in general, focusing on packages (like unlocked or second-generation packages) is best practice.
The great thing about packages is that Salesforce does all the work or ‘magic’ for you. The downside is that not all metadata types are packageable.
Are you considering a move towards Git? Explore Hutte, a visual tool that enables seamless integration with Git for streamlined development workflows.
Start your free 30-day trial, or check out our demo below.
At Hutte, we enable you to visually leverage the benefits of Git-based development without needing CLI. We have removed the barriers Git can pose as Hutte is a web UI to SFDX that allows for visual Salesforce version control.
You can also create and manage Salesforce scratch orgs and sandboxes. There is no need for code, which means there is no hassle involved.
Furthermore, you don’t need to install or learn Git, as Hutte’s UI is already integrated into Git hosting tools, like GitLab and Azure.
From these hosting providers, you can also view the changes you made, including your pull request, in a line-by-line comparison format.
If you're interested in delving into Salesforce Git version control, take a look at our user-friendly guide on its implementation and installation.
Hutte is truly one of the best tools that we use. Product owners, Salesforce solution architects, business analysts — anyone on our team can easily and visually accomplish the tasks that would otherwise take a lot of clicks, time, and coding.
Once you have created a Hutte account with us, you will start from a fresh environment by taking a scratch org from the pool.
You can name your org referencing the issue tracking system you use (such as Jira). Once you’ve named the org, you will have your environment in place.
With Hutte, you don’t need to share your sensitive and confidential Salesforce org credentials manually. You can simply one-click login, and you can then do your work on the platform.
You can create new SFDX metadata in your org. In this coding example, we have selected an Apex class.
To create a change, you will go to “Setup.” You will then select “Object Manager” from the dropdown menu located on the left.
As you have access to the data model, you can make any change you desire. To implement a change to a field, for example, you will select “Field & Relationships.” In this instance, we are changing the “Help Text.”
Once you have added in your help text, you will save it. To view your changes, you will go to the “Changes” tab.
In this example, the changes had the following impact to the org:
From here, you can describe what you have done, and you can select what you want to include from the changes you committed.
By employing Hutte, users of any background or skill level can effortlessly collaborate with Git, make code modifications, and create pull requests.