What is the recommended workflow using Liquibase and Git?

Question

Recently we started using Liquibase. It didn't occurred yet but we imagined what would happen if two developers commits changes in the change log file to the shared Git repository.

How to solve or avoid a merge conflict? To broaden this question some what:

What is the recommended workflow using Liquibase in combination with Git?

Example scenario:
- Michael changes a column in table 'customer'.
- Jacob changes a column in table 'account'.
So both developers added a <changeSet> to the same changelog file changelog.xml.

EDIT :

As commented the scenario isn't that much exciting indeed. Assume Jacob was the last one to push his code. He has to pull first. Gets a warning there are merge conflicts to solve. He solves the conflict by keeping both parts of the code, that of Michael's and his. Updating the database with Liquibase gives no problems.

Advanced example scenario:
-Michael changes the name of column 'name' of table 'customer' in 'first_name', commits and pushes.
-Jacob changes the name of column 'name' of table 'customer' in 'last_name' and commits.
-Jacob gets a merge conflict when pulling Michael's code.
-Jacob and Michael discussed the conflict and agreed it has to be 'last_name', which Jacob commits and pushes.
-Michael pulls the solved conflict and runs a Liquibase update. He gets an error: column "name" does not exist

Answer 1

TL;DR: Add /path/to/changelogfile.xml merge=union into .gitattributes file.

I've seen some discussions on having separate files. There are two ways of having separate files in liquibase:

1. Use the includeAll tag and let keep pushing new files to the folder.
2. Use the include tag for each separate file in the master file to dictate the order.

Both ways will still cause problems: (1) includeAll will just pick files on lexicographic order of file names, which works fine if changelog is executed every time there a new change is submitted, but this will fail if you want to deploy to a brand new file. Unless you have a naming strategy to dictate the order. But this will still be a problem in case of Michael and Jacob working at the same time: they will probably use the same name, which results in conflicts. (2) Both Michael and Jacob need to edit the last few lines of the master file. In other words: merge conflict!

The actual solution is not to change your liquibase strategy. Just keep the same strategy you've been following so far. The root of the problem here is the source control and merging mechanism. A liquibase changelog file is essentially a history. Think of it as a release notes file where developers just keep adding their work to the last line of the file. In that case, doesn't matter if two developers add two lines add the end, both should go regardless of the order. So, the solution is to create a .gitattributes file in the root folder of your git project (if you don't already have one) and add the following line to it:

/path/to/changelogfile.xml merge=union

This is still not fail-prof. To address your advanced example scenario, I can't think of any automatic strategy or workflow. The developers should communicate when they are touching the same table (or same db objects). This scenario is not only a "file" conflict, but also a semantic conflict. That's when a good CI comes handy. The developer who commits and merge the code last will get the error, and needs to get in touch with the one who won the race at first.

Note, maybe your Git portal does not support merge strategy and you still get merge conflicts on pull requests (aka merge requests). But still, when you see that and try to merge back or rebase to resolve conflicts, the conflict is already solved. I know GitLab does support it. Not sure about Github or BitBucket.