We are using ant + dbdeploy, we had been using phing + dbdeploy in the past.
Unfortunately there is no automated way of handling these type of changes, so we had to come up with an agreement. Our branches are temporary, when feature/bug is resolved, they are usually removed after the changes are merged into master branch. Few basic rules:
1. Make sure everyone knows you will be or you already have changed database structure and/or
This way conflicts are prevented. If Alice on changing something Bob already changed in a different branch, Alice can either use Bob's delta or make sure your change will not affect it.
2. Only one person is allowed to merge changes into master branch
When Charlie is merging branches into master, Alice and Bob help him resolve any DB delta issue. For example, Alice created
123_create_table_user.sql and Bob
123_alter_table_message.sql. Depending on the changes, there are two possible outcomes,
3. You are the owner of your local database
In above case, both Alice and Bob need to make sure their dbdeploy's
changelog is in sync. If there are any problems when running dbdeploy because the values in the table are different than the delta scripts, it's Alice's and/or Bob's fault.
What we have seen so far, most frequent database changes are done at the beginning of the project, when everything is done on one branch. Later on, even with 5 or more developers each working in their own branches, we rarely run into database conflicts.