Version Control & Collaboration
Built-in Git workflows designed for data teams. Branch, review, and merge dbt changes with confidence, right from the IDE.
Git-Native Development
Every dbt project in dbdeux is backed by a Git repository. This means:
- Full version history of every change to every model
- Branch-based workflows so experiments never affect production
- Code review with pull requests before changes go live
- Rollback to any previous state instantly
Branching
Create and Switch Branches
Create feature branches directly from the IDE. Each branch provides an isolated workspace:
- Changes on your branch are invisible to other team members until you merge
- Multiple team members can work on different branches simultaneously
- Branches can target different environments for testing
- New branches are cut from the live head of the source branch on your provider, not a stale cached commit, so you always start from the newest code
If you are sitting on the default branch (main or master), dbdeux nudges you with a one-click prompt to create a feature branch first, so you do not accidentally commit straight to the protected branch.
Branch Naming Conventions
dbdeux suggests branch names based on your work:
feature/add-customer-ltv-modelfix/order-total-calculationrefactor/staging-layer-cleanup
Refresh Branches
The branch picker has a refresh button that re-syncs the branch list directly from your Git provider. Use it when someone else created or deleted a branch and you want it to show up without reloading the app.
Delete a Branch
You can delete a branch you no longer need straight from the branch picker. Because deleting removes the branch on your Git provider too, it goes through a safeguarded confirmation:
- Any uncommitted changes on the branch are counted and shown before you confirm, so you never lose work by accident
- You type the branch name to confirm the deletion
- The branch is removed on the provider and cleaned up locally
Switching Branches
When you switch branches, open editor tabs are remapped to the file records on the branch you moved to, so you keep working on the same files in their new-branch state instead of seeing stale content. If the branch you were on no longer exists (for example someone deleted it), dbdeux falls back to a valid branch instead of leaving you stranded on a missing one.
Because unsaved editor edits live only in your browser, dbdeux guards the switch when you have unsaved changes. It lists exactly which files have unsaved edits and lets you either move your current changes onto the branch you are switching to (drafts are flushed and carried over) or cancel and save first. A branch switch never silently discards work.
Git Provider Support
dbdeux integrates with all major Git providers:
| Provider | Features | Self-hosted |
|---|---|---|
| GitHub | Full support including PR creation, commit status, webhooks, and token-free access through the dbdeux GitHub App | GitHub Enterprise Server supported (with a personal access token) |
| GitLab | Full support including MR creation, commit status, webhooks | Self-managed instances supported |
| Azure DevOps | Full support including PR creation, service hooks, commit status | Azure DevOps Server supported |
| Bitbucket Cloud | Full support including PR creation, commit status, webhooks | Bitbucket Data Center supported |
Connect your provider from the user menu under Connect Git Provider, using a personal access token or app password. Self-hosted instances are supported by providing your custom base URL during setup. See the Token Setup Guide for required scopes and step-by-step instructions for each provider.
Update, Disconnect, and Reconnect
Need to rotate your token or switch to a different account? You have two options in the same dialog:
- Update the token in place: Paste a new token to replace the stored one without disconnecting. This is the quickest way to rotate a credential that is about to expire.
- Disconnect: Clear your stored credentials entirely, then reconnect with a new token when you are ready.
Either way:
- Your repository links remain intact (no need to re-create projects)
- Useful when rotating tokens, switching from a personal to a service account, or troubleshooting auth issues
If a token is rejected or lacks repository access, dbdeux surfaces an actionable error that tells you what to fix rather than a generic failure.
Repository Access Without a Token: the dbdeux GitHub App
Many companies do not allow personal access tokens on their GitHub organization, and even where they are allowed, a project that runs on one person's token stops working the day that person changes role or leaves. For GitHub projects you can connect through the dbdeux GitHub App instead. Your GitHub administrator installs the App on the one repository the project uses, sends you a number, and nobody on the team has to create, store, or rotate a token.
Every Git project has one Repository access choice, picked when you create the project and changeable later in Version control settings:
| Option | What it uses | Good for |
|---|---|---|
| Personal access token | One of your saved Git credentials | Any provider, including GitLab, Azure DevOps, Bitbucket, and GitHub Enterprise Server |
| dbdeux GitHub App | An installation your GitHub administrator approved, with no token anywhere | Teams on github.com that block tokens, or want access tied to the organization rather than a person |
| Public | Nothing: an anonymous, read-only clone | Public repositories you only read from. Switch to a token or the App before you commit or push |
What your GitHub administrator does. They do not need a dbdeux account. dbdeux shows them the steps, including the exact repository to pick:
- Open the dbdeux App install page on GitHub (the link is in the project dialog)
- Pick the organization or account that owns the repository
- Choose Only select repositories and tick the project's repository
- Review the permissions and click Install. GitHub opens a page whose address ends in
/installations/<number>; that number is the installation id - Send you the installation id, or simply the whole address
The App asks for Contents: Read and write (clone, commit, and push), Metadata: Read (required by GitHub for every App), and Pull requests and Checks: Read and write (the Slimmer CI comments and status checks). If your organization already installed the App for Slimmer CI before it asked for write access, an organization owner accepts the new permissions once in the installation settings.
What you do in dbdeux. Choose dbdeux GitHub App, paste the installation id or the address, and click Check access. dbdeux asks GitHub right away and saves nothing until the installation is confirmed as active, covering this exact repository, and able to read and write it. The result names the installation, the account it is on, how many repositories it covers, and its Contents access.
One method, no silent fallback. The option you choose is the only way the project reaches its repository. Branches, pulls, commits, history, pull requests, editor runs, scheduled jobs, and Slimmer CI builds all use it. If an administrator later suspends, narrows, or removes the installation, dbdeux does not quietly borrow someone's token or fall back to anonymous access: Git actions on the project stop with a message saying exactly what changed. Once it is fixed on GitHub, Re-check installation brings the project back, and Change lets you enter a new installation id or switch to a token at any time.
When a check does not pass, the card says why in plain words and links to the page on GitHub that fixes it:
| You see | What it means | Who fixes it |
|---|---|---|
| Connected | Active, covers this repository, can read and write | Nothing to do |
| Repository not selected | The installation does not include this repository | GitHub administrator adds it under Repository access |
| Missing Contents: Read and write | The new permission has not been accepted yet | An organization owner accepts it in the installation settings |
| Installation suspended | The App was suspended on that account | GitHub administrator unsuspends it |
| Installation not found | The id is unknown to GitHub or the App was uninstalled | GitHub administrator reinstalls and sends the new id |
| Belongs to a different App | The id is for another GitHub App | GitHub administrator installs the dbdeux App and sends that id |
| Not a github.com repository | The App works only with github.com | Use a personal access token for other hosts |
Commits made through the App are still yours: they carry your name as the author and, with Signed Commits turned on, your signature, so GitHub still shows Verified. Setting the access method, changing it, and every check are recorded in the Audit Log. In a workspace that allows each developer a personal token override, the override applies only to projects that use a personal access token; on an App project the settings tell you your own credentials are not used there.
| Personal access token | dbdeux GitHub App | |
|---|---|---|
| Works when the organization blocks tokens | No | Yes |
| Tied to one person's account | Yes | No, to the organization's installation |
| Someone has to rotate it before it expires | Yes | No |
| Access limited to one repository | Depends how the token was made | Yes, the administrator picks the repository |
| Checked before it is saved | On first use | Yes, with Check access |
| Removed access is reported with a reason | Generic authorization error | Named reason and a link to fix it |
Pull Requests
Open Pull Requests from the IDE
When your changes are ready for review:
- Commit your changes with a descriptive message
- Push your branch to the remote
- Click Create Pull Request to open a PR in your Git provider
dbdeux takes you straight to your provider's own "new pull request" page with the branch and base already filled in, so the PR is created and reviewed in the tool your team already uses. This deep-link approach works across GitHub, GitLab, Azure DevOps, and Bitbucket.
Preview Your PR Before You Open It
Open the branch compare sheet from the Changes panel to see exactly what your pull request will contain before you create it:
- Every commit your branch is ahead by, and how far behind the base it is
- The full list of files the PR will change
- An auto-generated PR title and description drafted from your commits, carried straight into your provider's create-PR page so you are not staring at an empty form
This removes the usual surprise of opening a PR and discovering it includes more (or less) than you expected.
Review with Context
Pull requests created from dbdeux include rich context:
- Schema Diff: Automatically shows the schema impact of the code changes
- Model list: Which models were modified, added, or removed
- DAG impact: Visual representation of affected downstream models
- Run results: Optional CI results showing that models build successfully
Reviewing and Discarding Changes
The Changes panel lists every file you have modified on the current branch:
- Click a changed file to open it in the editor so you can review the change before staging or committing it
- Stage and unstage files individually or in bulk, including brand-new files you just created, so nothing is silently left out of a commit
- Discard a file to roll it back to the last committed state when you want to abandon an edit, and this works for deleted files too, so you can bring back a file you removed by mistake
Branch State at a Glance
A status strip at the top of the Changes panel keeps you oriented without dropping to a terminal:
- Ahead and behind counts show how your branch compares to its base branch in real time
- Merge base pulls the latest base branch into yours in one click when you have fallen behind
- A manual refresh re-checks the state on demand, and the panel also polls in the background
- The Changes button turns amber when your branch needs attention, such as when it is behind or has conflicts to resolve
- dbdeux tracks the last commit it synced for your branch and notifies you automatically when your local branch falls behind the remote, so you know to pull before someone else's work drifts out of sight
Change Indicators You Can Trust
The dots in the file tree and the count on the Changes button come from the same Git status the panel itself reads, so the three never disagree. A file shows as modified because Git says it is modified, not because the editor thinks you touched it.
That distinction matters in practice. Save a file back to its original contents and the indicator clears, instead of leaving a phantom change you cannot find. A folder is marked as changed only while a file inside it actually is, so a collapsed folder never keeps a stale dot after you commit or discard the work underneath it. Being behind the remote is shown as its own behind pill rather than counted as a local change, so "someone else pushed" and "I edited something" stay visibly different states.
A Commit Never Loses Your Work
Occasionally a staged file cannot be included in the commit, for example because it was changed or removed underneath you between staging and committing. When that happens, the commit tells you: it names every file it could not include, and those files stay in the Changes panel exactly as they were.
The alternative, which is what makes this worth calling out, is a commit that reports success while quietly leaving a file behind. Then the file disappears from the panel, and you find out days later that the change was never in the branch. Here the count you committed and the files still waiting always add up.
Auto-Drafted Commit Messages
When you stage changes, dbdeux drafts a commit message from what you actually changed, following the standard summary-line convention. Accept it as-is or edit it. No more blank commit boxes or vague "update models" messages.
Signed Commits
A signature is a small stamp on a commit that proves who made it. Turn on Signed commits in your User Preferences and every commit dbdeux pushes for you carries one, so on GitHub each of them shows the green Verified badge your team already trusts on commits made from a laptop.
Nothing to install and no key to look after:
- Click Create signing key. dbdeux creates a key for you and keeps the private half in its own secure store, where it never leaves and is never shown to anyone
- Copy or download the public key, the half that is safe to share, and paste it into your GitHub signing key settings. The preferences panel links straight to the right page and shows the fingerprint so you can confirm they match
- That is it. Commits dbdeux pushes from now on show Verified
A few details worth knowing:
- Signed as shows the name and email written into every signature. GitHub only shows Verified when that email is a verified email on your GitHub account
- Pause without losing the key: switch Sign my commits off and commits go out unsigned until you turn it back on; the key is kept
- Replace key creates a new one for future commits. Commits you already pushed keep their old signature and stay Verified for as long as the old public key remains on your account
- Delete key pushes future commits unsigned; existing commits keep their signature
- The commit toast tells you the outcome of each push, signed or not, so a missing public key is noticed on the first commit rather than at review time
- Providers whose services do not accept a signature yet receive the commits unsigned, and the panel lists which ones those are
Why it matters: many organizations require verified commits on protected branches. Until now that ruled out committing from a browser-based editor, or meant handing a personal key to a service. Here the key never leaves dbdeux, each person has their own, and a compliance rule that says "every commit to main is verified" is met from the same place the work is done.
Changed-Line Markers
As you edit, the editor gutter marks every added, changed, and removed line against the committed version of the file. Hover a marker for details, and use the status bar legend to read the colors at a glance, so you always know exactly what you have touched.
Pulling and Conflicts
When you pull the latest changes from the remote, dbdeux tells you exactly what happened:
- A clean pull confirms your branch is up to date
- If the pull produces conflicts, a warning tells you how many files conflicted and marks them in the file tree, and dbdeux opens the first conflicted file for you so you can start resolving immediately
- Open each conflicted file and choose Keep my changes, Keep incoming, or merge manually to resolve it
- Pulling again is blocked until every conflict is resolved, so you never stack conflicts on top of conflicts
Team Collaboration
See Who is Working Where
The IDE shows real-time presence indicators:
- See which team members are currently online
- See which files are being edited by others
- Avoid conflicts by knowing when someone else is working on the same model
Merge Conflict Resolution
When branches diverge, the IDE resolves conflicts in a full side-by-side merge editor built on the same engine that powers the code editor:
- Incoming changes on the left (read-only) next to an editable merge result on the right, seeded from your version
- One-click chunk accept to pull in an incoming change without hand-editing
- Edit the merge result directly for anything that needs a human decision
- See the resolved file exactly as it will be committed before you finish the merge
File History and Blame
Understand not just what changed, but who changed it and why, without leaving the editor:
- File history: Open the history sheet for any file to see its commits over time, with authors and timestamps
- Inline line blame: Turn on an annotate column, in the style of a desktop IDE, that shows the date and author of the commit that last touched each line. Adjacent lines from the same commit are shaded together and the line under your cursor expands to full commit details, so you can trace a piece of logic straight back to the change that introduced it
These views are backed by your Git provider, so they reflect the same history your team sees everywhere else.
How It Compares
| Capability | dbdeux | dbt Cloud IDE | Local Git + CLI |
|---|---|---|---|
| Branch state (ahead/behind, merge base) | Live strip in the Changes panel | Limited | Manual git status / git fetch |
| Auto-drafted commit and PR text | Drafted from your changes | Manual | Manual |
| PR preview before opening | Branch compare sheet with file list | Not available | Manual git diff |
| Conflict resolution | Side-by-side merge editor, one-click chunk accept | Basic | Text markers in your editor |
| File history and line blame | Built into the editor | Limited | git log / git blame in a terminal |
| Changed-line markers | Live gutter vs committed version | Limited | Depends on local editor setup |
| Provider deep links | GitHub, GitLab, Azure DevOps, Bitbucket | GitHub-centric | Manual |
Audit Trail
Every action is tracked and attributable:
- Who changed what, when, and why (via commit messages)
- Which runs were triggered from which commits
- Full history accessible through the Git log in the IDE
- Integration with external compliance and audit tools via webhooks