# OpenCode + Git: The Underrated Duo > Source: > Published: 2026-08-18 13:48:20+00:00 Let me be honest about my credentials, because they are the point of this essay. I have used git for roughly fifteen years. I can clone, commit, branch, merge, push, pull, stash, log, revert, reset. I can fix a rebase mess I created, and I have. By any reasonable definition I *know git*. And yet, in two days of working with **OpenCode** — the terminal AI agent running big-pickle, a 200k-context open-weight LLM — I produced more real automation than in most of those fifteen years. Not because my git skills suddenly improved. Because I finally had someone to **wield** git, and everything around it, the way an experienced engineer would: thinking, deciding, and building in a loop with me as the one who approves. The claim of this essay is simple: **git is not underrated — everyone knows it is essential. What is underrated is the whole stack working together: OpenCode, git, and the documents and skills I have written, wired into one loop that tracks, stages, analyzes, commits, and pushes — across multiple repos and two accounts — even for a single article. And the reason it works is not the model — it is the orchestration.** Here is how I got there. I did not discover this because I read about it. I discovered it by watching OpenCode work a real, messy, multi-account problem while I sat at the approval gate. The setup was genuinely complicated. My articles live in ai-thoughts, which is mirrored to **two** GitHub accounts (j3ffyang and negtivspace), and those accounts also run two profile repos whose READMEs should show the same portfolio as PORTFOLIO.md. Keeping all of that consistent by hand is the kind of job I have always half-done: it works, then it drifts, then I spend an afternoon fixing it and never finish. This time, I did not fix it by hand. I described the goal, the agent drew a plan, I approved each step, and over two sessions we built something that never drifts again. And the most uncomfortable part of watching it happen was this: **the agent used git better than I do.** It inspected clean worktrees, staged only intended files, bumped submodule pointers, pushed to both remotes, and rolled back cleanly when a step went sideways. All the things I *could* do, but never bothered to *orchestrate*. The mental model that changed everything is a division of labor: None of this requires me to become a git master. It requires me to understand git *just enough* — enough that when the agent asks approval to run shell or python or gh, I know what those are generally doing, even if I cannot recite every flag. That is a much lower bar, and it is the bar that unlocks everything. Everything below is real, from a single weekend of work. Each row is: what I wanted, what OpenCode + git built, and what it saved me. Look at the last three rows carefully. They form a ladder: first I build a generator, then I use it, then I make using it automatic. That is the compounding effect, and it is the whole reason the weekend was worth it. To be precise about what “the combination” means: publishing one article does not touch one repo. It reads my [AGENTS.md](http://agents.md/) rules, stages only the intended files, analyzes the diff, commits in the right style, pushes to both accounts’ mirrors, bumps the submodule pointer, and triggers the profile-sync workflows that refresh two profile READMEs. That is several repos, two accounts, and a handful of automations — for one Markdown file. None of this is hard *as git*. As a system, it is the workload of a small team compressed into an afternoon. What actually happened, reduced to its shape. On my side is a thought-flow; on the agent’s side is a workflow. They meet at the approval gate. The loop is the real product. Every stage has a job, and skipping one shows up immediately: People ask whether an AI agent can really replace the experience of working with experts. I think that is the wrong question. The right question is: **can one agent, well-orchestrated, behave like a small team?** Watching this weekend, the answer was yes — because each problem pulled a different “specialist” out of the same tool: The same session that edited an essay also debugged a GitHub Actions failure and bumped a submodule. That breadth — not depth in any single domain — is what “a team of experts” actually feels like in practice: a small team’s 3–5 days of work, done across a weekend. This is far less than people fear. Three things made the weekend work: Time, obviously — but the honest accounting is more interesting than “it was fast.” The direct savings were real: hours of manual file renaming, prose re-wrapping, README drift-fixing, and cross-account copy-paste, compressed into two sessions. But the compounding savings matter more. Every tool we built became capital for the next request. The generator built on day one was used on day two. The workflow built on day two will run forever. Each session ends with the system slightly more automated than it began, which means the *next* session starts slightly smaller. That is the difference between using git as a chore and using OpenCode + git as a lever. The chores scale linearly; the lever compounds. If you remember only five things: btw, i use arch [OpenCode + Git: The Underrated Duo](https://blog.devgenius.io/opencode-git-the-underrated-duo-33ffe7178dbb) was originally published in [Dev Genius](https://blog.devgenius.io) on Medium, where people are continuing the conversation by highlighting and responding to this story.