I’m unsure what is best practice for storing my sfdx projects in git repos. Do I store each project in one repo, or can I store multiple projects in one repo?
This is what I’m thinking it should be
├── GitRepoName //aka "Source of Truth" │ └── Project1 // aka "Artifact" aka "sfdx project" │ └── Project2 // aka "Artifact" aka "sfdx project" │ └── Project3 // aka "Artifact" aka "sfdx project"
I’m not super savvy with git yet, but I would think once I created a new scratch org, I could push each artifact into the scratch org by switching directories and using
It appears to me that things could be difficult if I’m switching between projects, with say Project1, 2, 3, in the scratch org, and I do
sfdx force:source:pullin my Project1, it could also pull the source that came from Projects 2 & 3, right?
Read the answers on What’s the best practice for putting multiple projects in a git repository? for some possible solutions (over on Stack Overflow). My biggest concern is that if you end up screwing up something in one of the projects, and you try to fix it, you might end up reversing changes in other projects by accident. If you do decide to follow the path of multiple projects in a single repo, consider using “orphan branches”, which will help isolate accidental destructive changes. There’s details in the answer linked above and also on git-checkout, look for the
In my personal opinion, you would be better off with separate repositories, because it avoids the possibility that you’ll merge something into something else that you didn’t mean to do, which can cause an absolute mess of things. While it’s “easy” to clean up most mistakes, merging two entire projects together might result in a lot of downstream messes, since you’ll basically be forced to backtrack and rebase. Every developer depending on your repo will be forced to undo all their work and clone the repository fresh to avoid any lingering mixups. You don’t want this to happen.
Keep in mind, too, that a git repo essentially contains every copy of every change ever committed to the repo when you clone or pull; obviously, this is not literally the case in terms of disk space, but it does make the cloning process longer. This may make clones and pulls more painful than they need to be in terms of processing time. There’s other ways of dealing with this, but simply having one repository per project makes that management trivial.
Also, git servers do tend to have an absolute maximum repository size. You’ll reach this size sooner if you have multiple, active projects all going at once in the same repository. It might not matter with just Apex Code and Lightning, but if you’ve got a lot of heavy duty files (data load files, static resources, documents, attachments, etc), you’ll exhaust your limits faster than you would with separate repositories.
Note that sfdx uses a project configuration file to pull source. So if you have project1, project2, and project3, and you’re in project1’s directory, you’ll pull the contents of project1 into it, but not project2 or project3. However, if you screw up a username/alias even once, you’ll end up having to reset/clean your repository and you’ll risk losing work in the scratch org. The last thing you want to do is have a major conflict of (for example) 2,000 files and have to try and manually resolve it.