Git isn’t new. This isn’t a post about discovering version control.
What’s changed is where Git fits in data work — and why it’s now showing up in workflows where it never used to.
For a long time, Git simply wasn’t part of most data workflows because it didn’t need to be. Data work lived in a different lane than application development. It was internal, exploratory, and tightly coupled to the person doing the work. You wrote a SQL query, adjusted a notebook, or ran a small Python script to answer a question. The work stayed local, the feedback loop was short, and the impact was contained.
That workflow made sense.
You typed every line. You knew what changed because you made the change. If something broke, you could usually trace it back to the last thing you touched. Lightweight safety nets — rerunning a query, stepping back a few edits, saving a copy — were enough to keep things moving.
That assumption is starting to break.
AI didn’t just make coding faster. It changed how data work gets done. Instead of carefully modifying one piece at a time, you ask an agent to improve something and it reshapes multiple files, rewrites queries, updates configuration, and introduces new dependencies in seconds. Even when it’s just you and a single agent, work is now happening on your behalf, not entirely through your hands.
That’s the inflection point.
Once work happens this way, the role shifts. You’re no longer just executing changes — you’re responsible for overseeing them. You need to understand how the system evolved, not just whether the output looks right.
And that’s where Git naturally enters the picture.
First, as a way to make change explicit. When modifications span files, layers, and tools, memory and simple undo mechanisms stop being sufficient. You need a reliable way to see what changed, when it changed, and what the system looked like at each step along the way.
Second, Git has become the place where work turns into something real. Modern platforms don’t watch folders on your laptop — they watch repositories. When Git changes, systems rebuild, redeploy, and update automatically. Git is no longer just recording history; it’s increasingly the boundary between “in progress” and “live.”
This isn’t about data teams suddenly deciding to adopt software engineering practices.
It’s about the work itself becoming software — and needing the same kind of structure to stay understandable and controllable as it evolves.
Undo Works in Tools — It Breaks Down Outside Them
Undo works exceptionally well inside tools like Power BI.
If you add a visual and don’t like how it looks, you remove it. If you adjust a DAX measure and the numbers drift, you step back. You can experiment freely because the tool understands the full context of what you’re doing. The data model, transformations, calculations, and visuals all live inside the same managed environment.
That’s not accidental. Undo works here because Power BI reports are like Word documents — a single file that contains everything you’re working on.
When everything happens inside the tool, Power BI knows what a “change” means. It can safely rewind because it controls the dependencies, the execution model, and the boundaries of the system. As long as your logic lives inside that box, stepping backward is predictable.
This is one of the biggest reasons these tools took off.
You didn’t just get visualization. You got built-in versioning, deployment, and access control wrapped into a single experience. You could build something, publish it, and your team could immediately use it—authenticated, hosted, and stable—without thinking about infrastructure or coordination.
The problem starts when the work no longer fits inside the box.
As soon as transformations move outside Power BI—into SQL, Python, Spark, or upstream pipelines—the Undo button loses context. You might still be looking at the same report, but its behavior now depends on logic that Power BI can’t see, track, or reason about.
At that point, the report isn’t the system anymore.
It’s the surface.
This is where AI accelerates an already fragile boundary.
Undo works when you’re making changes inside the tool. It doesn’t help when an agent rewrites a query upstream, moves a transformation from Power BI into a database, or changes how a dataset is produced entirely. The report may still load. The visuals may still render. But something important has shifted—performance, correctness, cost, or behavior—and there’s nothing meaningful to undo from the report editor.
From Power BI’s perspective, nothing changed.
From yours, the workflow drifted.
That’s the mismatch.
Undo assumes a single system with a shared understanding of state. Modern data workflows aren’t built that way anymore. They span tools, languages, execution engines, and now automated agents making coordinated changes across all of them.
When something goes wrong in that world, you don’t need to undo a single action.
You need to return the workflow to a known state.
That’s where version control enters—not as a replacement for tool-level history, but as a layer above it. Something that tracks how the entire workflow evolved, not just what happened inside one UI.
For a long time, data teams didn’t need that layer. Tools like Power BI handled it implicitly. Once logic escapes the tool—and especially once AI starts helping generate and modify it—Undo solves yesterday’s problem.
The next problem is understanding how work actually became what it is.
Git Is Where Work Turns Into Reality
One of the reasons tools like Power BI became so widely adopted is that they didn’t just help you build things — they helped you share them.
You didn’t have to think about where a report lived or how someone else would access it. You built it, published it, and it was available. Hosting was handled. Authentication was built in. The environment already existed. Sharing meant sending a link, not instructions.
That experience shaped expectations across data teams.
Publishing wasn’t just about making something visible. It was the moment work became usable by other people. Deployment, access, and stability were bundled together in a way that let teams focus on analysis instead of mechanics.
That model works as long as the work stays inside the tool.
The moment logic moves outside Power BI, publishing a report stops being the same thing as deploying the system. The report may still load, but the behavior now depends on SQL queries, Python code, pipelines, schedules, and execution environments that live elsewhere. Power BI can authenticate users to the report, but it can’t guarantee how the data behind it was produced.
For a long time, this created a gap.
Code gave you flexibility, but getting something live meant manual steps, cloud consoles, and fragile handoffs. BI tools gave you a clean publish button, but limited where logic could live. Many data workflows ended up split between the two — powerful, but awkward.
That gap has started to close.
Modern platforms have recreated the “build → publish” experience for code-based workflows, with Git as the boundary instead of a UI button. Instead of clicking Publish inside a tool, you push changes to a repository. Systems watch that repository. When it changes, they rebuild, redeploy, and update automatically.
Git becomes the publish event.
This is a subtle but important shift. The same place that records what changed is now also the place where changes become live. Versioning and deployment are no longer separate steps handled by different tools. They’re aligned.
That alignment matters.
When Git is the publishing boundary, commits aren’t just notes to yourself. They’re the transition point between experimentation and behavior that other people rely on. A commit doesn’t just describe change — it activates it.
In that sense, Git has taken on a role that will feel familiar to anyone who has worked in Power BI.
It’s the modern equivalent of the Publish button — not for a single report, but for an entire workflow that now spans tools, code, and environments.
What This Looks Like in Practice
In practice, this workflow is far less technical than it sounds.
Most of the time, you’re not living in the command line.
If you’re working in Visual Studio Code, Git is already built into the UI. There’s a dedicated Source Control panel where you can see what changed, review diffs, and write a short message to capture what you just did. You don’t need to know commands to use it. You don’t need to think about syntax. You’re interacting with Git the same way you’d interact with comments or tracked changes in a document editor.
That’s not accidental. GitHub is a Microsoft company now, and the integration is deep. VS Code even includes built-in GitHub assistance that can help stage changes, write commit messages, and resolve conflicts. If you want, you can offload almost all of the mechanics to the tool.
The same thing applies when work happens in the cloud.
You might ask an agent to make changes directly — in a browser-based editor, a cloud environment, or even from your phone. You describe what you want, the agent edits the code, and when it’s done you can simply ask it to commit and push the changes. The agent already understands Git. You’re just giving it direction.
What matters here isn’t how you interact with Git.
It’s how you think about it.
The Central Command Hub
The most useful way to understand Git in this workflow is as a central command hub.
Your laptop, cloud editors, deployment platforms, and AI agents all orbit around a shared repository — usually hosted on GitHub. That repository is the place where work becomes coordinated and durable.
Once you see it that way, the flow becomes straightforward:
-
Local changes
You edit files locally, usually in VS Code, reviewing and refining work as you go. -
Commit = checkpoint
A commit is a named snapshot of the workflow at a moment in time. It’s your “this version makes sense” marker. -
Push = sync to the hub
Pushing sends those checkpoints to the remote repository so everything else can see them — teammates, deployment systems, and agents alike. -
Remote = shared source of truth
This is where work converges. It’s the version everyone and everything agrees on. -
Pull = rejoin shared reality
This step matters more than it used to.Work doesn’t only happen on your laptop anymore. You might:
- use a cloud agent like Codex while away from your desk
- experiment in a browser-based editor
- ask an agent to refactor something overnight
- switch tools and continue later in Claude locally
-
Pulling is how you reconnect all of that back to your machine. It brings down the latest changes so you can continue exactly where the work left off, regardless of where it happened.
You don’t need to memorize commands to use this model. You can click buttons. You can ask an agent to handle it. The mechanics are interchangeable. The structure is not.
Once Git becomes the hub, everything else lines up around it.
Where Deployment Fits
That same hub is what modern deployment platforms connect to.
If you’re building a simple Next.js app, platforms like Vercel make deployment almost invisible. You connect a GitHub repository, and every push becomes a new deployment. You get a live URL, logs when something breaks, and a clear link between code and what’s running.
If you need more control — over cloud resources, networking, or integrations — services like AWS App Runner or Google Cloud Run follow the same pattern. They watch the repository. When it changes, the system updates.
This is why platforms like Replit felt so transformative early on. One-click deployment removed friction that used to block data teams from sharing real applications. What’s changed is that this experience is no longer confined to a single ecosystem. You now have multiple ways to get there, with different tradeoffs around cost, control, and scale.
Across all of them, Git is the constant.
It’s where:
- changes are reviewed
- checkpoints are created
- deployments are triggered
- work stays synchronized across devices, environments, and agents
You can avoid the command line entirely.
You can let agents handle the mechanics.
But the structure remains the same — and that structure is what makes fast, AI-assisted workflows manageable.
The Manager’s Job Isn’t to Type — It’s to Stay Oriented
The moment you introduce automated helpers into your workflow, your job changes.
You’re no longer responsible for typing every line or remembering every edit. That work can happen faster, and often better, when you let agents handle translation, syntax, and boilerplate. What you’re responsible for instead is orientation — understanding how the system evolved and deciding whether the direction still makes sense.
That’s the manager’s job.
Git isn’t what turns you into a manager. The work does that on its own. Git is what makes the role survivable.
It gives you a reliable way to see how things changed over time, to mark moments you trust, and to move forward deliberately when experiments don’t pan out. It turns fast, automated change into something you can reason about after the fact.
At the same time, Git has quietly become the point where work becomes real. When repositories change, systems rebuild. Deployments happen. Other people start relying on the result. Git isn’t just documenting the work anymore — it’s the boundary between exploration and production.
That combination is why Git now shows up naturally in data workflows where it never used to.
Not because data teams suddenly decided to adopt software engineering discipline.
But because data work crossed a threshold.
Once logic spans tools, languages, and execution environments — and once AI starts helping generate and reshape it — lightweight safety nets stop being enough. You need structure that lets you move fast without losing your footing.
Git provides that structure.
You don’t have to live in the command line.
You don’t have to memorize commands.
You don’t even have to think of yourself as a developer.
But if you’re working with a growing team of automated helpers — even if that team is just you and an agent — you need a way to stay oriented as the work accelerates.
That’s what Git gives you.
Not control over the robots —
but control over the direction they’re taking you.