I want to set up Git repo for our production org to start version control.

I am unsure which metadata components I should fetch into my repo.

If I select all components from the Force IDE for retrieval then it would include everything including components which came out-of-the-box (eg. Milestone / Evernote objects etc.) which we would never need to version control.

Is there a standard minimum set of components that we should retrieve to initialise our repo ?

2 Answers 2


Disclaimer: I work for Gearset.

It can be really tempting when you're starting out with version control to immediately try to put all your metadata into a repository. Unfortunately, there are some downsides to that approach:

  • While the majority of metadata can be successfully version controlled, some types such as Site.com don't work that well because of automated changes made by Salesforce. These types will always be out of sync between your repository and org.
  • Some metadata can be undeployable due to API limitations.
  • The high volume of metadata can be overwhelming to jump straight in with and the burden of management can slow down your development cycle until you get everything working.
  • As you've identified in your question, development flows won't affect every metadata type - there's no need to deal with the above possible headaches if you don't need to.

We generally recommend people start with a controlled subset and incrementally expand it. This has multiple benefits:

  • You can make sure the subset you've chosen can be deployed with a high degree of reliability, and be more confident that unforeseen problems with the version control process won't hold up the development cycle
  • When you add extra types, if you start having issues it's easier to tie those issues back to which types are causing problems
  • Each time you encounter a challenge with your version control deployment process, it erodes confidence in the process and reduces appetite for pursuing the version controlled approach

Whatever process you set up, it needs to work for your team. If it's a gargantuan effort to set up before any benefits are realized there's a risk that the process will fall by the wayside. On the other hand, if a team can start seeing small benefits quickly then hopefully the process will snowball of its own accord.

An example of the metadata types we often recommend starting with as their very first attempt might be:

  • Apex class
  • Apex component
  • Apex page
  • Apex trigger
  • Custom object
  • Global value set
  • Standard value set
  • Profile

Once your process is up and running end to end with a small set like this, you can begin to add more types as required. The final set will really depend on your team's customizations and requirements.

The above is slightly adapted from the "What metadata to version control" section of our version control whitepaper, which you can read in full here if you're interested: https://gearset.com/assets/version-control-for-salesforce-whitepaper.pdf

  • Thanks @olane - the whitepaper helped cleared up some concepts for me. Can you clarify the steps to "refresh an existing [sandbox] from your master branch" ? (mentioned in Whitepaper). I have a sandbox with outdated code - how do I "push" my master branch onto the sandbox so as to start with latest master code ? Do I use ANT deploy tasks to do this ?
    – Tickle Me
    Commented May 31, 2018 at 4:40
  • Absolutely, you can use ANT for that, or the SFDX command line tool. There are also several vendors that offer tools which can push from git or local files to an org, including Gearset.
    – olane
    Commented May 31, 2018 at 14:16


No, there is no standard minimum; it depends on your intent.

The minimum depends on your intent. If you're going to move to DX eventually, it should include everything that you would need to reconstruct your org from a blank template. This includes all fields, layouts, custom objects, custom metadata, custom links, all custom code, processes, flows, etc.

If, instead, your intent is just to make sure you don't lose code, then the default Force.com IDE settings (classes, triggers, Lightning bundles, Visualforce, and static resources) should suffice.

One thing that you can do to make your life easier is to start bundling your stuff in to packages. This will automatically resolve dependencies and allow you to build minimum metadata configurations that you can pull out.

Just go to Setup > Create > Packages or Setup > Package Manager, create a new package, and add the elements you want. All of the dependencies will be resolved for you and can be pulled down via Salesforce DX, Force.com IDE, VS Code, Mavens Mate, or whatever other tool you prefer.

Converting your org to a repo will take time, but the end result is worth it. If you're prepared to take the time to build packages, then you'll eventually be prepared to use DX, which gives your repo the ability to be the source of truth for all your orgs.

  • Our intention is to make sure that any developer can be given a dev sandbox that has been "wiped and replaced" with the latest version of production org GIT repo (SFDC_REPO) - so that we know that the developer will be working on the same version as production. This is why we have selected ALL metadata components to retrieve using Force IDE - and then source control ALL these components - as we are "casting our net as widely as possible" to avoid missing components that may be required when deploying to our production Org.
    – Tickle Me
    Commented May 30, 2018 at 5:44
  • @TickleMe Yeah, that's a painful experience. And I would know from said experience. Sandboxes are meant to be refreshed, not updated from source control, and it's a problem. This is why I mention DX. The sooner you can move to DX, the sooner you can use the correct tool for the problem at hand. You'll still end up selecting all metadata, and you'll still need to build packages, but the end result is a beautiful way to quickly spin up a new org that matches any version of production you have in your repo.
    – sfdcfox
    Commented May 30, 2018 at 5:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .