Ask Iche: I built a version of me my colleague can ask about git

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

For six months, my colleague has sent me the same message: "Iche, git is doing something again."

She's a Flutter developer learning a Node.js backend. The code isn't where she gets stuck. Git is. Push, pull, fetch, and the classic: "why was my push rejected?"

Every time, I stop what I'm doing and explain the same few fixes again. She doesn't need a git course. She needs me, at the moment git breaks.

So this weekend I built a version of me she can ask instead.

Ask Iche 🌿 is a friendly git buddy that runs on her own laptop. She picks her project folder, then clicks a big button (📍 Where am I?, 💾 Save my work, ⬆️ Upload my work, ⬇️ Get latest, 🤝 Fix a conflict) or types what happened, like "my push got rejected". Then:

1. Ask Iche reads her repo, read-only.
2. A plain rules engine plans the exact git steps. No AI here.
3. Gemma 3 4B, running locally through Ollama, explains the plan in plain words.
4. A guard checks every command right before it runs.
5. It runs one step at a time, only after she clicks Run. Risky steps need a typed "yes".
6. It checks the repo again after each step and carries on from where things really are.

Conflicts show up as two cards, Yours and Theirs, never as <<<<<<< markers. Merges never open vim. And if Gemma isn't running, Ask Iche still works, using built-in explanations.

Beyond push and pull, it covers the things she hits next:

• 📦 Named stashes, to put work aside safely
• ↩️ Undoing commits, with a backup branch made first
• 🧹 Cleaning up a branch before review
• 🍒 Copying one commit from another branch
• 🌿 Branches: switch, create, rename, delete, even GitHub's copy
• 📜 History, in plain words
• 🎓 Learn mode, a tiny quiz

The real goal is that she needs me less.

"Ask Iche is really cool. It helps new devs navigate git with ease, and not only them: any developer who struggles with git can easily make use of it. It makes git simpler and easier. I love it, Iche. I guess I won't have to disturb you again for any git issue, haahaa."

— my colleague, after trying it

Demo

A 5-minute walkthrough on a throwaway branch: a push that would be rejected, a real conflict, stash, branches, undo, the hard stops and Learn mode. I trimmed Gemma's waits and sped it up slightly. On my CPU laptop, Gemma takes 8–17 seconds to start talking.

Code

G00dS0ul / ask-iche

A local AI git buddy for beginners. Code plans the steps, Gemma explains them in plain English, and nothing runs without your OK. Private, offline, $0.

Ask Iche 🌿

A local AI git buddy for beginners. It reads your real repo, makes a safe plan, explains it in plain English with Gemma, and runs each step only after you say yes.

I built it for my colleague of 6 months. She's a Flutter dev learning a Node.js backend, and git (push, pull, fetch, conflicts) is where she always gets stuck. Until now the fix was "ask Iche". Now she can ask Ask Iche. And her work repo never leaves her laptop.

Built for the DEV Hacktoberfest Weekend Challenge: Build for a Friend.

What it does

node ask-iche.mjs "my push got rejected" ~/projects/my-app

1. Reads your repo (read-only): branch, ahead/behind, unsaved files, conflicts.
2. Makes a plan with plain code, not AI: e.g. add → commit → pull → push.
3. Gemma explains what's going on and why each step is needed, streamed live…

View on GitHub

Plain Node.js and one HTML file. Zero npm dependencies, MIT licensed. node app.mjs opens the web app on 127.0.0.1:4321, and node ask-iche.mjs is the terminal version. Both run the same engine.

How I Built It

I let three open models plan. None could.

My first idea was the obvious one: give a model the repo state and let it decide what to do. I installed Ollama on my laptop (16 GB RAM, CPU only, no GPU) and pulled three open models.

Each one got the same scenario: her branch is 1 commit ahead and 2 behind, she has unsaved files, and her push was rejected. The right answer is add → commit → pull → push. Two runs each, strict JSON output.

Model	Run 1	Run 2	Time
gemma3:4b	❌ Flipped ahead/behind. Only git pull, labelled "safe"	✅ Correct summary, ❌ only git fetch	53–66 s
qwen2.5-coder:3b	❌ add → commit → push with no pull, so the push fails again	❌ Pulled before committing the unsaved changes	44–50 s
qwen2.5-coder:7b	✅ Correct summary, ❌ ignored the unsaved changes	❌ Called it a "conflict"; pull --rebase fails with unsaved changes	92–109 s

All the outputs were valid JSON. None of the models produced a correct plan in both runs. They labelled nearly everything "safe", and their answers changed between runs.

That's when I stopped letting the AI plan.

The code plans, the model teaches

Think doctor and nurse. The code is the doctor that decides the treatment. Gemma is the nurse who explains it kindly. The nurse never changes the prescription.

 her click or message
        │
        ▼
 Hard stops ───► dangerous? red card, nothing runs
        │
        ▼
 Collector      read-only git → plain facts
        │
        ▼
 Rules engine   facts + intent → exact steps (no AI)
        │                       ┌───────────────────────────┐
        ├──────────────────────►│ Gemma 3 4B via Ollama     │
        │                       │ explains, streamed live   │
        ▼                       └───────────────────────────┘
 Guard          allowlist check on every command
        │
        ▼
 Runner         she clicks Run → one step → re-check → repeat

The rules engine is deterministic: the same repo state gives the same plan, every time. I tested every plan by actually running it on throwaway repos until each one ended in sync. That covered a rejected push, a merge conflict, a new branch with no upstream, a detached HEAD, a pull with unsaved work, a missing git name or email, and "just force push it". If the plan is wrong, the tool is dangerous. If it's right every time, she can trust it.

Why Gemma

Then I reran the test with a smaller job. Same facts, but the steps were already decided. The model only had to write a summary, one reason per step, and a tip.

Gemma 3 4B gave one correct reason per step, in order, and was consistent across both runs, with the friendliest tone of the three (51 s cold, 26 s warm). Qwen 2.5 Coder 3B was faster (15 s warm), but its reasons didn't match the steps. It attached "no conflicts, so you can push" to git pull.

For a tool whose whole job is to calm down a nervous beginner, that settled it. Gemma didn't win the planning test. It won the explaining test, and explaining is the only job I give it.

How Gemma is used

Gemma has four jobs in the app:

• Explaining plans. A summary, one reason per step, and a tip. The prompt tells it to speak to her as "you", never change or reorder the steps, never invent files or numbers, and never mention conflict markers.
• Explaining conflicts. For each clash, Gemma gets the original, her version and the teammate's, and writes three short lines: YOU:, THEM: and NOTE:. It describes what changed. It never picks a side or writes code.
• Understanding her message. Keywords come first, because they're instant: "rejected" means push, "conflict" means resolve. Only vague messages go to Gemma, and it has to pick from a fixed JSON list of intents (or "unknown") at temperature 0. Then Ask Iche double-checks: "Sounds like you want to push your work. Right?"
• Fallbacks. Every step has built-in text. If Gemma skips a line, rambles, or Ollama isn't running, the gaps get filled. Gemma can make the explanation nicer, but never missing.

One choice mattered a lot on a CPU: line formats instead of JSON. Waiting about 26 seconds for a full JSON answer felt like the app had frozen. So Gemma replies in simple lines (SUMMARY:, 1:, 2:, TIP:), and each line appears as it's written:
Here's the core of the prompt (trimmed):

You receive FACTS about her repo and STEPS that are already correct.
- Do NOT change, add, remove, or reorder the steps.
- Only mention files, branches, and numbers that appear in FACTS.
- Never mention <<<<<<<, =======, or >>>>>>> markers.
Reply in EXACTLY this format, nothing else:
SUMMARY: <1-2 sentences on what is going on and why>
1: <reason for step 1>
2: <reason for step 2>
TIP: <one short learning tip>

Later I went further: the plan and its Run buttons now appear straight away, and Gemma's words type in beside them. The code already knows what's safe. Gemma just catches up and explains.

Testing with real Gemma also caught real mistakes. It named the wrong stash, invented a branch name, and said reset --soft "unstages" changes (it doesn't). Wherever a wrong word could hurt, the code now locks the text. Gemma makes it friendlier. It never makes it wrong.

Real numbers from my CPU laptop with gemma3:4b:

Case	First words	Total
Cold start	30.7 s	60.9 s
Typical plan	8–17 s	21–40 s
Conflict explanation	~16 s	22–27 s

Safety: a guard that trusts no one

Every command goes through the guard right before it runs, no matter who suggested it:

Rule	What it covers
Never allowed, even if a plan asks	Plain push --force / -f / --mirror, rewriting or deleting a shared branch like main on GitHub, interactive rebase
Only when a plan step allows it, and she types "yes"	reset --hard (backup branch first), push --force-with-lease on her own branch, deleting one branch on GitHub
Blocked as soon as she types it	git push --force, git rebase -i, git clean -fd, git checkout ., git commit --amend → a red 🚫 card with nothing to click
Anything else unknown	Blocked

Merges run with no editor (GIT_EDITOR=true and --no-edit), so she never lands in vim.

The web app is local, but I still locked it down. The server listens only on 127.0.0.1, checks the Host header (to block DNS-rebinding tricks), and needs a fresh random token every time it starts. Other websites open in her browser can't tell it to run git. I tested it: no token gets a 403, and so does a wrong host.

Same brain, friendlier face

I built the terminal version first. It worked perfectly, for me. But she's scared of git and the terminal. The runner only talks to a small ui object (say, ask, confirm, showConflict), so I kept the brain and gave it a web face. Events stream to the browser, and each button click answers the waiting question. Not one line of git logic was duplicated.

Lessons I learned the honest way

A copied folder is not a sandbox. My first real run was on what I thought was a test copy of a real team repo. But the copy still pointed at the real GitHub remote, so the push went there: a new branch with 16 work-in-progress files, announced by our team's bot. Nothing was overwritten, and I told the team. The tool did exactly what its plan said. The mistake was mine: I never checked where that folder pointed. It's the best argument I have for showing every plan before anything runs

"All good" wasn't all good. The first version of 📍 Where am I? said "Nothing to do. You're all set!" while 5 files were unsaved. For a beginner, that's the worst possible message, because she'd think her work was safe. Now it shows a summary and the next step ("You have unsaved work. Choose Save my work…"). "All set" only appears when the repo really is clean and in sync.

Two moments I'm proud of

It fixed a conflict on its own repo. After I renamed the project from "Ask Ise" to "Ask Iche", my laptop had 8 changed files, GitHub had a commit I didn't, and the pull hit a real conflict in the README. So I ran the tool on itself. Gemma spotted it: "it looks like both of you made the same change." I picked Keep mine, it saved a backup, finished the merge and pushed. First try, and I never saw a single <<<<<<<.

The web app shipped its own code. The first thing the new UI ever did was upload itself. I clicked ⬆️ Upload my work, typed one sentence, clicked Run three times, and its own code was on GitHub.

Handing it over

Then I handed it over. She tried it, and her verdict made my weekend: "I guess I won't have to disturb you again." Honestly, she still can. But now she doesn't have to.

Ask Iche won't replace me, and that was never the point. The code plans, the model teaches, and nothing runs until she says so. It's the version of me that's always awake.

Why Does Open Innovation Matter?

• Her code stays on her laptop. She works in a real team repo. With Gemma running locally through Ollama, nothing about it goes to a server she doesn't control. No API key, no account.
• It's free to run: no API bill, no subscription. Gemma runs on her CPU, so the explanations don't need the internet. Only push and pull do, because they talk to GitHub.
• I could test before I trusted. Because the models are open-weight and run locally, I could put three of them through the exact same git scenario as often as I liked. Swapping models is one environment variable (ASK_ICHE_MODEL).
• I could change the model's job. The shootout showed that small models can't plan git safely. Because I control the whole stack, I moved the planning into code and gave Gemma the job it's good at. A 4B model on a CPU is plenty when the code does the planning.
• Open tools all the way down: Gemma (open-weight, under the Gemma Terms of Use), Ollama, Node.js, and git's own git merge-file for splitting conflicts into Yours and Theirs.

Prize Categories

Best Use of Gemma. Gemma 3 4B (open-weight) runs locally through Ollama and does all the explaining in Ask Iche: plan explanations, the YOU/THEM/NOTE lines for conflicts, and turning free text into an intent from a fixed JSON list. It streams simple line formats so words show up fast on a CPU, and every line has a built-in fallback.

---

Credits: Gemma by Google (open-weight, Gemma Terms of Use), Ollama for local inference, git (including git merge-file) and Node.js.

I used an AI assistant to help write parts of the code and this post. The design decisions, the real-world testing and the final words are mine.