Team Collaboration in Schema Design with Git

How Teams Share One Schema Model Through Git

To share a single database schema model across a team, commit your DbSchema project file to a shared Git repository. Developers create a dedicated branch for each schema change, update the tables, and push their work. The team then reviews the visual diff to approve changes before merging the branch and syncing the final schema directly to the database.

This page covers the Git mechanics: the model file, the branch, the diff and the conflicted table. Team roles, review responsibilities and the wider design process are covered separately in collaborative database design.

Why Use Git for Schema Design?

With Git, your team gains:

• A shared history of all schema changes
• Branching and merging for parallel work
• The ability to review changes before they go live
• Confidence that everyone works on the latest schema

The reason this works is the file format. A DbSchema model is stored as a single .dbs file, and that file is plain indented XML holding the schema plus every diagram, layout, group, colour and comment. Git diffs it as text[1], so a schema change reads as added and removed lines in a pull request rather than as an opaque binary blob.

How It Works in DbSchema

1. Open Model → Git Collaboration in DbSchema.
2. Clone your team's repository from that dialog - GitHub, GitLab, Bitbucket or an internal Git server.
3. Save the .dbs model file inside the cloned working copy.
4. Commit and push from the same dialog. Pull, Branch, Stash and Model History sit next to them.

Git Collaboration is a full Git client built into DbSchema, not a link out to the documentation. DbSchema documents the workflow in its own Git collaboration guide. It carries a Working Tree pane, a Branch, Graph, Author and Commit Message log, and a commit box with author name and email. From this point, every design change is versioned and shareable with the team.

One edition note before you plan a workflow around this. Saving the model to a file and schema synchronization are Pro features; the free Community Edition connects, reverse-engineers and draws interactive diagrams, but it does not write the .dbs file that Git would version. A team doing this needs Pro.

Best Practices for Schema Design in Git

pull/push the changes

work on different branches

insert commit message

Git Dialog in DbSchema

The Git Collaboration dialog is where the whole loop happens: pull and push the changes, switch between branches, and type the commit message that explains the schema change.

1. One Repository, One Schema Model

Keep your .dbs file in a shared Git repository.

This way, everyone is working with the same schema design, not scattered copies.

2. Use Branches for Team Work

When multiple people work on the schema:

• Create feature branches for new designs (e.g. feature/add-payments).
• Each teammate commits changes in their branch.
• Merge into main after review.

This avoids overwriting each other's work.

Create feature branches

Merge safely into main

Different Branches in Git

3. Communicate Through Commits

Use commit messages to explain schema changes:

• “Added Customers table with PK”
• “Linked Orders → Customers with FK”
• “Renamed column email_address → email”

This makes it clear what each teammate did and why.

add a clear commit message

Commit message

4. Pull Before You Push

Before pushing your own schema changes, always pull.

This ensures you see what your teammates committed, and conflicts are resolved early.

5. Compare and Review

DbSchema compares in two directions, and both are worth running before a merge:

• Two versions of the model - Schema → Compare Model with Other Model From File, pointed at the .dbs saved from the other branch.
• The model against a live database - Schema → Create or Upgrade Model in the Database, or Refresh Model from Database for the other direction.

Both open the same Synchronization Dialog: a per-object tree with one side's value on the left and the other's on the right, and Merge and Commit buttons on each row. Rows are labelled plainly, so a table that exists in the model but not in the repository version reads as EXISTS in the model, MISSING in the other side.

This table EXISTS
in the Model

This table is MISSING
in the Repository

Review changes

Resolving Schema Conflicts Between Branches

Git merges the .dbs file as text, the same way it merges source code. Two developers who touch different tables usually merge with no conflict at all, because their changes land in different parts of the XML. A conflict appears when both branches edit the same lines - the same table, the same column list.

For example, imagine two developers both edit the users table on separate branches:

• Developer A adds a last_login column to track user activity.
• Developer B adds a profile_picture_url column to the same table.

Resolve that in DbSchema rather than in the raw XML. Check out each branch in turn and save its version of the model under its own file name, then run Schema → Compare Model with Other Model From File against the second file. The Synchronization Dialog lists the users table with both new columns, one side against the other, and you accept them row by row with the Merge and Commit buttons. Save the merged model over the conflicted file and complete the merge in Git.

Note what DbSchema does and does not do here. It does not resolve the Git conflict for you inside the Git Collaboration dialog - there is no merge-conflict view in that client. What it gives you is a per-object comparison of the two models, which is what turns an unreadable XML conflict into a decision about two columns. Schema synchronization is a Pro feature.

Schema Design Workflow with Git

Here's a simple workflow teams can follow when using DbSchema with Git:

1. Clone the repository to get the latest .dbs schema model.
2. Branch off main for your task (e.g. feature/add-customers-table).
3. Design changes in DbSchema - add tables, keys, or update diagrams.
4. Commit with small, clear messages.
5. Pull before push to sync with teammates and avoid conflicts.
6. Push your branch to share changes.
7. Merge back into main after review.

This cycle keeps schema design structured, collaborative and reviewable.

Conclusion

Without Git, database design often drifts: changes get lost, work gets overwritten, and no one is sure which version is the latest.

By versioning the .dbs schema design file in Git, your team avoids these problems.

• Everyone works on the same design.
• Every change is tracked and reviewable.
• Mistakes can be rolled back.
• A conflicted table becomes a row-by-row decision instead of an XML merge.

DbSchema builds the Git client into the design workflow, so your team can move fast without losing track of the schema.

Download DbSchema and put your .dbs model in your team's repository. Saving the model to a file, schema synchronization and the model comparison this article describes are Pro features, and the download includes a 15-day Pro trial you can extend by another 15 days.

Sources

1. Git