Deploying content types, fields, views, site settings (everything that is not content) from one environment (local) to another (stage, prod etc.) in Drupal 8+ works by exporting the currently active configuration (stored in the database) into YAML files. The most common approach is to simply export all your site's configuration at once. Drupal takes care of that. You just specify the folder where you want these YAML files to be located in your project (at best outside the Drupal root). Then you uploaded all these YAML files or
git push and
git pull them to another environment and import the whole config there into the database. The export and import can be done by either using the UI or by using Drush.
Now when you add new features to your site locally (a new content type with fields for example) you simply export the whole config again. With some version control system like Git you'll then see that most of the already existing YAML files didn't change and only some new YAML files have been added. Simply upload/push the changes or the new files into another environment where you import the config again. The new content type with the fields now should have been created.
Of course, things can get more complex than what I described above, especially when working with lots of people on feature-rich and content-heavy projects. Then it can become necessary that you want some config to be ignored from getting exported or imported. Let's say you want to prevent that some API keys get exported. Or you want to prevent that some setting on the live site gets reset when you import the config again. Or maybe you always want to have some additional modules enabled only locally during development. Then there's the Config Ignore and the Configuration Split module to cover that.
Exporting/importing isolated config
This basically has been the way how you used to deploy configuration in Drupal 7. Now this approach can be used during local development to sync for example only one isolated content type or paragraph type and its fields across many multi-site instances. Of course you could rebuild the content type in every single instance manually yourself, but you can also use the Features module to have it create a module for you which only contains the config of this isolated content type and its fields. Then simply enable this feature module in all other multi-site instances to have the content type created there as well. And finally export the config on all instances for deployment as described under "Configuration management".
When you now change the content type on one instance, Features will recognize these changes and lets you recreate the feature module which then also contains the changes. These changes will be recognized by Features in all other instances where this module is enabled and you can re-import the changes into every instance's database; after which you finally export every instance's global config again, for deployment. Since every feature module actually is simply another Drupal module you can also use them to bring a certain isolated feature like a content type and its fields to any other unrelated Drupal 8+ site.