GitEasy

How GitEasy works

Six cards. Click through them to see what each part of GitEasy does — in plain English, with a small picture for each idea.

Card 1 of 6

Five commands, not forty

The problem GitEasy actually solves.

To save your work and publish it with raw Git, you have to type four separate commands — stage, commit, pull, push — and remember the right order. Get any of them wrong and you get a scary message.

GitEasy collapses those four into one: Save-Work. The four Git steps still run, in the right order, with sane defaults. You just don't have to remember them.

git add --all git commit -m git pull --rebase git push Save-Work 'your note' Four steps → one verb.
What runs under the hood 
git add --all
git commit -m "your note"
git pull --rebase
git push

Every step is logged in plain text. You can read exactly what GitEasy ran.

Card 2 of 6

One safe engine

Every Git call goes through the same private helper.

Inside GitEasy, no command shells out to Git directly. Every single Git call goes through one private helper called Invoke-GEGit.

That means one place to log every call, one place to scrub credentials, one place to catch failures and turn them into plain-English messages. If you ever wonder what exact Git command GitEasy ran, there's one file to read.

You Save-Work (public) Invoke-GEGit the ONLY place that runs git git.exe
Why this matters in practice

Any new public command that touches Git has to call Invoke-GEGit. There's no exception. That means when a security review finds a problem with how Git output gets logged, it's one place to fix it — not 21 places.

Card 3 of 6

A log file you don't have to read

Until you want to.

Every GitEasy command writes a small log file under %LOCALAPPDATA%\GitEasy\Logs. You don't have to read it. If a command worked, the log is silent.

But if something goes wrong, the log file tells you exactly what Git command ran and what it returned. And tokens, passwords, and IP addresses are stripped from the log before anything hits the disk. Old logs delete themselves after 30 days, so the folder doesn't pile up.

Save-Work scrub Save-Work.log git add --all exit: 0 git commit -m... %LOCALAPPDATA%\GitEasy\Logs Save-Work-20260522-093015.log Find-CodeChange-20260522-093142.log older logs auto-delete at 30 days silent on success, helpful on failure
Open the log right from PowerShell 
Show-Diagnostic           # open the most recent log
Show-Diagnostic -List     # list recent logs
Show-Diagnostic -All      # open the logs folder
Card 4 of 6

The safety check before every save

GitEasy refuses to make a mess.

Before any save, GitEasy checks whether your folder is in the middle of something — a half-done merge, a paused rebase, an unfinished cherry-pick. If it is, GitEasy stops and says so in plain English.

This is the single most important safety promise. No accidental commit on top of a tangled state. You finish the in-progress operation first, in raw Git if you have to, and then GitEasy is happy to save again.

Save-Work Is the repo in the middle of something? no save proceeds yes STOP plain-English message
What the check actually looks for

The private helper Assert-GESafeSave looks at .git\MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, and BISECT_LOG. If any of them exists, the repo is mid-operation and GitEasy refuses to add new work on top.

Card 5 of 6

Credentials never leak

Three places they could. Three places they don't.

Git can leak credentials in surprising ways. A token embedded in a URL. An error message that prints the URL back at you. A diagnostic log that writes the URL to disk. All real. All quiet. All catastrophic if you don't notice.

GitEasy blocks all three. A URL with embedded credentials is refused at input. Error messages are sanitized before you see them. Log files are scrubbed before they hit disk. All three are exercised by a formal kill-test suite.

3 leaks blocked URL leak https://tok@host → refused error leak "...token..." → sanitized log leak IP / token → scrubbed
How we know this is real

Two adversarial security passes (May 17 and May 20, 2026) found six total findings (three of them at "High" severity). All six are fixed. The kill-test suite lives in Tests/GitEasy.AuthHardening.Tests.ps1. The full record is in docs/SECURITY-FINDINGS-2026-05-17.md and docs/SECURITY-FINDINGS-2026-05-20.md.

Card 6 of 6

What GitEasy doesn't do

By design.

GitEasy is small on purpose. It doesn't rebase. It doesn't squash. It doesn't merge branches together. It doesn't sign commits or do partial-folder check-ins. It does not have a command for every Git verb.

Those are sharp tools for people who want them. They all still work — drop into raw Git in the same folder and nothing GitEasy did blocks you. GitEasy keeps its surface small so the people who don't want those tools never have to see them.

IN GITEASY Save-Work Find-CodeChange Show-History Show-Remote Test-Login Restore-File Undo-Changes New-WorkBranch ...and 13 more drop down to raw git USE RAW GIT rebase squash cherry-pick merge amend submodule worktree bisect signed commits LFS
The end-of-walkthrough recap

Five everyday commands. One safe engine. One log file per call. A safety check before every save. A credential surface that doesn't leak. A boundary that's honest about what's not included. That's GitEasy.

Read the full how-to →

1 of 6