Synapse Git
You set up synapse git by linking your analytics workspace to a source control repo. This integration lets engineers save scripts, pipelines, and notebooks as tracked files in branches. Data teams use this workflow to review code changes before pushing updates to production. Still, broad workspace roles often let developers run ad-hoc queries against live data anyway. Source control tracks file edits, but it does not govern live query execution. How synapse git integration works In a standard
Git Commit Signing (GPG, SSH): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up synapse git by linking your analytics workspace to a source control repo. This integration lets engineers save scripts, pipelines, and notebooks as tracked files in branches. Data teams use this workflow to review code changes before pushing updates to production. Still, broad workspace roles often let developers run ad-hoc queries against live data anyway. Source control tracks file edits, but it does not govern live query execution.
How synapse git integration works
In a standard workspace without source control, users save changes directly to the live service. Every edit overwrites the current version of a script or pipeline right away. Two engineers working on the same item can overwrite each other without warning. Linking a source repo changes how the workspace stores and publishes work.
When you set up synapse git, you pick a provider like GitHub or Azure DevOps. You point the workspace at a specific repo and pick a collaboration branch. Engineers then create their own feature branches from that shared branch to build pipelines. Every save writes a file to the active feature branch instead of the live workspace.
Once a feature is ready, the engineer opens a pull request in the repo. Teammates review the SQL scripts, notebook logic, and pipeline steps before merging the code. Merging into the main collaboration branch triggers the publishing flow inside the workspace. The workspace compiles the merged files into an deployment template and updates the live service.
Managing branches and workspace roles
Using source control requires aligning repo permissions with workspace roles. An engineer needs write permissions on the repo to save work to a feature branch. That same engineer also needs a workspace role to test scripts against compute pools. Teams often grant broad contributor roles so developers can test their branches without friction.
Teams also use automated pipelines to push changes from the publish branch to other stages. The workspace exports deployment files to a designated publish branch after every merge. Release pipelines read those files and push the updates to test or production workspaces. This setup keeps manual file edits out of production stages.
Still, admins must manage credentials and compute permissions in each separate workspace stage. Developers testing a branch in a shared workspace often use shared SQL pools. If those pools hold sensitive tables, any developer with compute permissions can query them. Branch rules in the repo cannot stop a user from running a query in the studio.
Git Commit Signing (GPG, SSH): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native source control solves and what it misses
Native repo integration solves version tracking and peer review for data assets. Teams gain a clear history of who changed a pipeline or script and when. If a new deployment breaks a nightly job, admins can roll back to an older commit. Code reviews catch logic bugs before those changes reach the scheduled production runs.
Still, source control only governs saved files, not live database sessions or ad-hoc queries. Workspace roles decide who can log in and attach to a SQL pool. Once a user starts a session, the git setup does not inspect individual statements in flight. An engineer debugging a branch can still run a broad select query on raw tables.
This gap leaves sensitive fields like emails, phone numbers, card numbers, and national IDs exposed during testing. Even if a pull request blocks bad code from merging, interactive studio sessions bypass branch reviews. Teams need runtime controls that inspect every query and rewrite matched fields in results before returning data.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does synapse git control who can query SQL pools?
No, repo integration only tracks saved files and code branches. Workspace roles and database permissions control who can run queries against SQL pools.
What happens to existing workspace items when I link a repository?
You can import existing scripts and pipelines into your collaboration branch during setup. Once linked, the workspace reads artifact definitions from the repo branch.
Can engineers run unreviewed code while working in a feature branch?
Yes, users with compute permissions can run debug sessions from any active feature branch. Pull request reviews only gate what gets merged into the collaboration and publish branches.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.