generally i think there is nothing special about developing with multiple people compared to any other application. Just use git or any other VCS in order to share changes.
What makes the situation in developing in studio a little bit worse compared to other applications is the fact that you drive a really fast car. This means that little changes in the steering wheel will have a higher impact on others that if you drive slower.
What i mean by this is the following: Since it’s that easy and fast to change the entity model in studio and the corresponding screens, there is a higher likelihood that the results you show your stakeholders make them change their minds faster about the outcome.
Generally this is a good thing (because “embracing change” is one of the core values of agile software development), but it also means that (at least in the initial phase of an application) that you’ll have quite a few changes in the screens and especially in the db migration scripts.
So what i would recommend you is, to truly understand the different situations can occur when dealing the database migration changes, since it might happen to you that changes from colleagues conflict or have not been applied to your local database and you have to figure out how to do this.
In the docs you will find a part which suggests not to use update db scripts at the initial phase of an application becaus of the problems described above.
To avoid code overlapping, you can e.g. try to slice your user stories in a way that they will allow this parallel working or every teammate might pick up issues that are not related to each other (but this is recommendation that is not tied to CUBA, although it is more relevant with studio).