In terms of multidevs, I recommend multidev-per-feature rather than multidev-per-developer, as you want the branching and review of items to be about the individual features/changes being added to the site rather than a developer only being able to have one branch out for review.
Working with Github and a CI service is definitely a great way to do this. This exact use case is what we’re developing Dropship CI for.
The scenario here is well described by Pantheon’s build toolks guide and I would generally recommend the github -> CI -> Pantheon workflow. Traditionally the most difficult part of this flow is setting up and maintaining the CI configuration. Pantheon has done a ton of great work around this with the build tools plugin, but if you’re looking for a less involved setup, we’d love some people to kick the tires on Dropship while we’re working on getting it ready to launch.
No matter what tools you use though, CI is definitely a part of a high-quality collaboration friendly setup. The main points are:
- Don’t commit your compiled styles to your source repo to avoid merge conflicts
- Don’t ship your compiled source with the repo to make ALL of your git ops faster
- Use a Git Flow-ish branching model where each feature is a branch that can be reviewed and merged independently
- Use some kind of config management (built into Drupal 8) that commits configuration to code so you can have config changes run on branch builds automatically.
There are often limitations that make this difficult, but these days if you use D8, Composer, CI, and something like Lando or LocalDev for local setup, its very achievable with a team of devs working with Pantheon.
WordPress can achieve some of this too, but some of the points like config management are just harder to do.
As far as db sync, generally the key is to export your changes to code so the database can simply be pulled down locally or cloned to multidevs and then a configuration import from code applies your new features/config.