Multiple developers working on Flyway and GIT

Question

I have a question regarding working on Flyway with Git.

How to organize the work?

Two developers can create new SQL versions but on Git I think there should be one version of code to see all changes.

I mean when I am creating VBA code I am pushing to Git only one workbook and all changes there are updated when new version is pushed.

What about Flyway and creating multiple files?

How to do it?

Answer 1

Working with git usually implies working with different branches across developers.

As long as each developer is working on an individual branch you would not experience any problems with "seeing all changes" (from the perspective of such developer).

You will, however, experience problems in cases where those different developers are applying their (potentially different) flyway migrations to the very same database schema. In such case you may either drop the schema before applying flyway migrations or use a separate database instance per developer.

Now remember flyway is using migrations for expressing the sequence of changes that will form the final schema (or database content). migrations with flyway are just files (text files with sql code or java classes). For further details you might consult the flyway documentation

If you are looking at a single branch, e.g. as a result of merging various (remote) copies or other branches, you will encounter the following cases:

1. new migration (aka new file)
   Such file will be added to the total set of migrations on the target branch. The main problem is ensuring (using a proper naming convention) that the new migration is executed at the proper place within the sequence of migrations.
2. modified existing migration (aka change to a file)
   After a merge the modifications are part of the file and as such visible to the users of that branch.
3. deleted migration
   Here the modification is becoming visible to the target branch immediately after the merge.

In any case (whether you are keeping the complete set of migrations as a single file (not recommended!) or as a set of files (possible distributed across various folders), there will be a exact version of what is the "current" state of the migrations for a given branch.

EDIT:

Consider the following example based on your additional information:

branch b1 has the following migrations:

• 03.02.12__creating table.sql
• 05.02.12__Altering table

branch b2 has: - 04.02.12__Adding Column.

After merge of both branches into master branch you will ending with:

• 03.02.12__creating table.sql
• 04.02.12__Adding Column.
• 05.02.12__Altering table

Given the dates being the versions the list above gives the sequence of application of these migrations by flyway from the master branch (according to lexical ordering).

As there is no files with identical name with the git branches the files are just living side-by-side in the final version in the master branch.