How Version Control Works in dex
Inside dex, the Git tab provides a real-time view of all files that have changed since your last commit. You can stage specific files, enter a commit message, and push your changes to a selected branch. Pulling the latest changes from remote ensures your workspace is always in sync with your team.
dex will automatically detect when two users are working on the same file and flag potential conflicts before they are pushed. These alerts help avoid overwriting code and enable smoother collaboration across distributed teams. All actions are fully transparent, making it easy to see who made what changes and when.
Each change is versioned, meaning you can inspect past commits, review historical differences in code, and revert to any previous version if needed.
How Git Integration Affects Flows and Automations
Uncommitted or unpushed changes in the platform will not be picked up by flows, scheduled jobs or triggers.
In dex, all Flows and automations run directly from the code that lives in your Git repository. This means that uncommitted or unpushed changes in the platform will not be picked up by scheduled jobs or triggers. If you want your updates to be used in production or reflected in any automated workflow, you must commit and push them first.
This behavior ensures that everything running in dex has a clear, traceable version in source control. It also reduces the risk of deploying untested or unintended code to production environments.
Environment Management Through Git
dex supports environment isolation and promotion using standard Git workflows. This allows teams to safely iterate, test, and deploy their data pipelines using well-established practices from software development.
A common pattern is to use Git branches to represent different environments. For example, your development environment may be linked to the dev branch, and your production environment to the main branch.
In this workflow, new code is written and tested in the dev branch. You can preview your models, validate test results, and iterate on your logic without affecting production. Once the code is stable and ready for deployment, the recommended promotion path is to switch to the production environment in dex (typically tied to the main branch), then perform a pull from the dev branch into main. This step brings all approved changes into the production environment.
After pulling, you can review the changes within dex’s Git UI, and then recommit and push them to the main branch. This ensures that your production environment only runs explicitly approved and promoted code—and it keeps a clean and auditable commit history for all deployments.
Working with Files in dex
The Git integration in dex tracks all project files, not just models. You can manage everything from schema.yml files to macros, documentation markdown, and seed files. This provides full traceability and reproducibility across your entire data project.
When you make changes, you can commit all relevant files together with a clear message that documents why the change was made. This makes it easier to debug, onboard new team members, or conduct reviews later.
Last updated
Was this helpful?