How can I have multiple people editing the same SQL Server Database?

Me and some friends are working on a school project, and I've been looking for a way to allow us all to work and edit on the same database just like we would on a VS project through GitHub.

I've tried importing the database into an SQL Database project on VS so we could work through GitHub, but I'm not sure if VS is as effective as the actual SSMS.

It doesn't matter if it's not through GitHub, I just want to know if there is a way for us to work on a database without having to export it and then import it again.

Edit: By 'editing' I meant just working on the database overall, make changes, get data, edit tables, etc.

> By 'editing' I meant just working on the database overall, make changes, get data, edit tables, etc.

The short answer is no: as of Feburary 2023 there is no established tooling (outside of experimental databases like Dolt) for distributed collaborative work on both design-and-data on an RDBMS, especially not in the SQL Server-based Microsoft/VS ecosystem.

The reason why is rooted in a reality of database-centric software development: the actual data within a database is irrelevant to working on the system that consumes and manipulates it (with exceptions1), this principle is what enables companies handling very sensitive data (such as medical records, etc) to get any work done: the devs work with fake, generated data that only resembles real-world data, while the real data about real people lives in a separate database that almost no-one can access but it will have the exact same design/schema as the developer's database with the fake data in.

If you want to collaborate on data and the design then the "best" approach with today's tooling _{in my opinion} is to have a single RDBMS database in the cloud2 like Azure SQL or Amazon RDS - but you should still have your database design/schema in source-control in an SSDT *.sqlproj project - and to not directly make design/schema changes to this database without going through SSDT - and only make data changes in this live/cloud database.

If you have collaborators that won't always be able to connect to this central single cloud-hosted database then you have a very hard problem to solve which is worthy of another question entirely (welcome to the CAP Theorem).

1: Exceptions like setup/config/"system" data, and seed data for bootstrapping, or data used in test-cases. Point is: designing a database for animal taxonomy doesn't require actual Latin animal species names, and designing a patient/medical database doesn't require having the real details of real people with real conditions stored in your git repository.

2: ugh, I hate that word