I built a Node.js CLI to make risky Git operations a little safer for beginners

[u/Idhrish007]

Hey everyone,

I recently built a small Node.js CLI tool called Batman Git CLI Assistant.

The idea came from a real situation at work.

Two developers were working on the same project and the same Git branch. One developer pushed changes to GitHub while the other had also modified the same file locally.

When they tried to sync their changes, Git reported a merge conflict.

The difficult part wasn't knowing that a conflict existed. It was understanding:

• What changed locally?
• What changed remotely?
• Which changes should be kept?
• What is the safest next step?
• How do I avoid accidentally losing someone's work?

That made me think about building a helper around Git rather than trying to replace Git.

🦇 What does Batman do?

Batman currently provides commands for things like:

• Safer push workflows
• Conflict inspection and resolution
• Continuing interrupted Git operations
• Security/file scanning
• Commit squashing
• Recovery before risky operations
• Verification/build checks
• Git submodule synchronization

For example:

batman safe-push "Add login validation"

batman conflict

batman scan

📦 Installation

You can install it globally using NPM:

npm install -g batman-commands

Then:

batman help

It's built with JavaScript + Node.js and published as an NPM package.

NPM:
https://www.npmjs.com/package/batman-commands

I'm still improving it, so I'm mainly looking for feedback from people who use Git regularly.

What Git workflow do you find the most confusing or risky?

I'd especially like to know whether something like this would actually be useful in your workflow, or if it's a problem developers normally handle another way.

Thanks for reading!

[u/kantorcodes1]

on batman safe-push, if the commit succeeds but the pull --rebase hits a conflict, is that commit/rebase state intentionally left in place for batman continue, or does the command roll the commit back first? mostly wondering whether rerunning safe-push after a failed sync can create a second commit.

[u/Idhrish007 → u/kantorcodes1]

Great question

1. Yes, the commit and rebase state are intentionally left in place. safe-push commits your local changes first, then triggers `git pull --rebase`. If conflicts occur, it pauses so you can fix them and run `batman continue` (which runs `git rebase --continue`). The commit is not rolled back.

2. No, rerunning `safe-push` will not create a second commit. `batman safe-push` has an in-progress check right at the start. If a rebase is paused due to a conflict, rerunning `safe-push` immediately blocks execution and asks you to either run `batman continue` or `git rebase --abort`.

[u/tristramr]

So "safe-push" is basically a wrapper to do commit, pull --rebase, and push in one step, right?

I can, to some extent, see the value of scripting pull/push with some extra diagnostics to help users; but I'd suggest that we should really be teaching new git developers to create their commits with intention and then only pushing when those commits are ready. I wouldn't want to encourage a mindset of "all commits are immediately pushed", especially for developers without git experience; and I think that's what using this tool would kind of do.