My client's Salesforce codebase/metadata is fairly large and we're hoping to switch to SFDX.

Figuring out which components go into which artifact is going to be a challenge - I expect we'll have a "main" artifact with most of the components and then a couple of other artifacts for things that are clearly dependency free.

Anyway, I digress! Is the idea with SFDX that you would have 1 repo per artifact or should you have 1 repo with all artifacts in separate folders i.e. 1 repo per production org?

If it's the latter are there any sample repos out there with multiple artifacts?

2 Answers 2


Andrew Fawcett has provided us with an open source demo you can clone and peruse.

Generally speaking, all of the artifacts related to your application should exist in one repo. This allows you to have dependencies and help automate the deployment process.

Of course, the general exception is that you have a repo so large that it takes forever to push, pull, clone, etc, it might be worth it to split it up into multiple repos. This generally complicates matters and should only be used as a last resort.

  • Nice one thanks! Deffo 1 repo for us then!
    – Force Hero
    Jun 7, 2018 at 6:42
  • As a follow up to this how do you force:source:push different artifacts to a scratch org?
    – Force Hero
    Jun 7, 2018 at 11:18
  • 1
    @ForceHero Push/pull is meant to be used for the default/active artifact; you'd modify your project file to determine which one is in use. For the others, you'd use DX packaging to install/upgrade the other artifacts. At least, that's my understanding. You might want to make a new question and see if anyone has a better/different solution, since my DX knowledge is still mostly theoretical.
    – sfdcfox
    Jun 7, 2018 at 12:31

On our ISV project we use "NVIE" git branches


So one repo , but multiple branches :)

We also have one SFDX Project ( folder ) by "artifact"

  • Source :
    • Dev branch (and its sub-branches for developments)
    • Quali branch
    • Pre-prod branch
    • Prod branch
  • Packaging : managed package, ISV specific, not applicable to clients not building ISVs

If you need to deploy only parts of SFDX project into an org, you can filter it using your own package.xml files and this sfdx metadatas filtering plugin

  • Publishing in Dev branch is made via Pull Requests from Dev Sub branches
  • Merging of branches from Dev to Quali , Quali to Pre-prod , Pre-prod to prod can be managed automatically with Jenkins Jobs
  • addendum: sfdx force:source:deploy is now available for filtered deployments Apr 18, 2019 at 15:59

You must log in to answer this question.

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