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
data
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, 123_create_table_user.sql and 124_alter_table_message.sql or 123_alter_table_message.sql and 124_create_table_user.sql.
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.