Generally, the schema of the database can change with time. Between develops, zero to a lot of schema changes can happen. Exactly what is a "best practice" for taking these changes?

For instance, let us say 2 designers are focusing on a task and taking advantage of git for source control. They agree to possess a develop Friday. Each start their work, checking in changes with database migration scripts that update to the present schema. When person A will get person B's changes, just how can they easily know which upgrade scripts to operate? When one is searching in a database on the server, just how can they are fully aware which version they're on? When the database captures the version number, this means that on Friday, among the people around the team needed to tell everybody else "Ok, everybody sign in, then I will write a script that updates the version number to another version and appearance it in."

It is possible to standard method to approach this? Thanks.

Consider writing one migration per database [structure] change, not per stable version of the system. Much like revisions of code: every change updates system and batches it's revision (not version).

Usually we store database revision (together with 'public' version) inside a special table. We sometimes store names of migration scripts which were put on this database, but it is more complicated solution. It's handy to inlude revision of database which may be after using migration within the file title. Last line in migration script updates migration version inside a special table.

To find out which migrations to use to concrete developer's database, you simply take all of the migrations which have greater revision number than revision of database that's saved inside a special table.