I'm a DBA, not a developer — here's how I save my SQL to Git without learning Git

GitEasy · May 2026 · 4 min read

The first time Git swallowed an afternoon of my work, I closed PowerShell, walked away from my desk, and told myself I’d figure it out tomorrow. I didn’t. I told myself the same thing the next week.

I’m a SQL Server DBA, but the file I just edited could just as easily be an RDL report, a stored procedure, or a PowerShell script — whatever happens to be on your screen on a given day. What it shouldn’t be is harder to save than it was to write.

Git makes it harder. The vocabulary alone is a tax on your day — fetch, pull, rebase, origin, HEAD, detached HEAD, fast-forward, stash. Half of those words mean something different than what they sound like. The other half exist because Git’s internal model leaked into its user surface and nobody ever fixed it.

What I wanted was simple. I had a file I’d just edited. I wanted to save it. I wanted to publish it. I wanted to know what had changed since last time. That’s it. Three things a non-developer does dozens of times a week, and Git made all three feel like a final exam.

So I wrote GitEasy.

What GitEasy is

A PowerShell module that wraps Git in plain English. The first five commands are the ones I needed on day one:

Find-CodeChange — what has changed?
Save-Work — save and publish in one step
Show-History — recent saved points
Show-Remote — where this folder is published
Test-Login — verify connectivity to the published location

There are sixteen more for when you’re ready, but I deliberately kept those out of the way. If you only ever use the first five, you have a working Git workflow.

GitEasy is on PowerShell Gallery. MPL-2.0. Windows PowerShell 5.1 and PowerShell 7.

Install-Module GitEasy -Scope CurrentUser

The walkthrough I wish someone had given me

Say I edited a stored procedure — dbo.usp_LoadDailyMetrics.sql. The same flow works for an RDL report or a PowerShell script. The folder is already a Git repository.

Find-CodeChange

The output, in plain English:

Modified files:
  dbo.usp_LoadDailyMetrics.sql

Run Save-Work 'message' to save and publish.

No raw git status. No “changes not staged for commit” — what does staged even mean to a DBA? Nothing useful. So GitEasy doesn’t say it.

Save-Work 'fixed null check in daily metrics load'

One command stages, commits, and pushes. If something fails — say, my login token expired — GitEasy tells me in plain English which step failed and writes the technical detail to a log file:

Could not publish your saved work. Your local save is intact.
Reason: authentication failed.
Run Test-Login to check your connection.
Log: %LOCALAPPDATA%\GitEasy\Logs\<timestamp>.log

No fatal: Authentication failed for 'https://...' with a forty-character SHA on the next line. I know what failed and what to do.

Show-History -Count 3

3 most recent saves:
  2026-05-25  fixed null check in daily metrics load
  2026-05-24  added retry on transient connection error
  2026-05-23  initial commit of metrics load proc

That’s the loop. Three commands cover most days. The other sixteen exist for when you’re ready to switch branches, undo a change, or hand the repo to a developer for a more complicated operation.

What GitEasy is not

It is not Git for developers. If you write code for a living and you live in git rebase -i, GitEasy is in your way. Use Git directly.

It is not a teaching tool. It will not turn you into a Git expert. It is the opposite — it is for people who would rather not become Git experts.

It is not finished. The AI-assisted merge-conflict tutor I want to build is not in the box yet. Today, if a merge conflict happens, GitEasy hands you back to Git and tells you so honestly. That’s a known gap, and the next thing I’m working on.

And it is one author’s tool. I built GitEasy for the workflow of one DBA. It has 569 Pester tests on both PowerShell hosts and a security-hardening pass against credential-surface findings, but it has not been hardened by a thousand users. If you’re a team of fifty, prove it on one workstation first.

Why I’m telling you this

Because I think the Git jargon problem is solvable for the non-developer half of IT — DBAs, sysadmins, change managers, compliance teams — and I’d rather build that than write another LinkedIn post about it. If you’ve ever closed PowerShell because the Git error message felt scarier than the change you were trying to save, this was built for you.

Try it. Tell me what’s missing. Bug reports are welcome on the GitHub repo. The first five commands are the contract; the rest is negotiable.

What command would you have added to the starter five?

← All posts