There are different types of hurdles you will need to overcome to deploy to a scratch org. The same issues apply if you're trying to deploy to a developer org (not developer sandbox), but scratch orgs allow you to overcome some of them.
From easiest to hardest:
- Org Edition and Features
- Org Settings
- Org-Specific Metadata
- Org-Specific Limits
- Known Issues
Org Edition/Features
Some metadata can only be deployed to orgs with specific features enabled. For example, the CurrencyIsoCode fields can only be deployed if the MultiCurrency feature is enabled during scratch org creation.
You need to identify which features to enable in your scratch org definition file.
Org Settings
Some metadata can only be deployed to orgs when other metadata has specific values. For example, Case.SourceId can only be deployed if the IsLiveAgentEnabled setting is enabled.
These settings are stored as metadata so you can store them under version control. You can also deploy them to an org so you can adjust them while troubleshooting deployment errors. (Although some settings can't be changed through the metadata API, or can't be disabled once enabled.)
sfdx force:org:create supports setting some of the org settings so you can update your scratch org definition file once you figure out which settings you need enabled.
Org-Specific Metadata
Some metadata can be tied to data in an org. You'll want to try to break these dependencies by updating your metadata.
For example, Workflow alerts can reference Users. Since these Users won't exist in the scratch org, you will probably want to update these to use Groups or Roles, which are stored as metadata, instead.
Custom Org Limits
You might have non-standard limits available in your production org such as an increased number of Sharing Rules allowed. This will have to be addressed through the new Org Shape functionality.
Known Issues and Bugs
There's at least one known issue related to history tracking that will might prevent deploying the metadata from a large production org to a scratch org for the time being.
If you run into other errors, check the known issues and report them.
Unfortunately the discussion on this question is no longer accessible, so I hope I am not treading ground that's already been reviewed.
Reviewing the permissions in a fresh SFDX Dev Hub trial organization may be helpful. Those orgs come with a single permission set ("Salesforce DX") that does nothing save to provide the following object access:
Active Scratch Orgs: Read, Edit, Delete
Namespace Registries: Read, Create, Edit, Delete
Scratch Org Infos: Read, Create, Edit, Delete
These are just object permission settings, not system-level permissions. (The Manage Environment Hub permission is not available in these trial orgs).
Does your permission set provide these object permissions?
Best Answer
How we started using SFDX was:
We created a new Github repo which will contain the source for our Salesforce application. We develop a managed package so when we started using sfdx we pulled the source from the managed package and converted it into the sfdx project structure. Now we have our sfdx project in the correct format and we make the first commit in the github repo. This checks in our project into version control.
Now we can start new development using sfdx. We do this by following the Git Feature Branch Workflow which you can read about here. Following this workflow we create a new branch for each new feature we are developing. The developer can create as many scratch orgs to complete this feature as necessary. After the feature is complete a scratch org is made to do QA in. After QA we merge the feature branch back into out develop branch and do it all over again.
That is just the way we use SFDX. Im sure there are other ways but this has been working well for us. I hope this gives some insight in how others use sfdx.