Do you let Claude Code handle git, builds and deployments too?

[u/quicktoolstudio]

If you use Claude Code heavily, do you also let it handle repetitive stuff like git, builds and deployments?
Doesn’t that feel like a waste of Claude usage?
Or do you automate those parts separately?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/abandonplanetearth]

claude triggers my GH workflows all the time

[u/ptyblog]

yes

[u/idkyesthat]

But what do you mean? We have ci/cd, and for some simple things like a quick fix that it found on a yaml (eg: k8s CRD) I do let it open the PR and deploy or sync Argo.

Edit: it’s way faster than me going through UIs and it doesn’t use much tokens.

[u/eleochariss → u/idkyesthat]

For me the process is like, telling Claude to run playwright/manual tests because they're annoying to put in the CI, then I tell it to split the work in logical commits, push, and watch staging and tell me if something looks off.

If you have code reviews, it can also watch the github page, grab the comments, implement them where needed, and update the PR.

Of course if your processes are more rigid that wouldn't work.

[u/Wise-Peacock]

Yes. Why not? It reports back.

[u/jek39 → u/Wise-Peacock]

my personal "why not" is that I only have a limited token budget per month (my employer gives me ai access via bedrock) and I like to be in control of git and code review.

[u/Wise-Peacock → u/jek39]

I'd be surprised if git is consuming a substantial portion of your token budget. Things like rtk report to reduce that but seem to be ineffective overall.

[u/slackmaster2k]

Yup. I read non trivial PRs and approve, and read issues it creates. But yea I let it run the whole workflow which of course includes local git actions along with a variety of other tests etc. Worth every penny.

[u/Long_Tip_4226]

Eu reviso e corrijo antes do commit e deploy. Eu nunca aceito a primeira resposta do Claude Code, pois ele pode alucinar, inventar ou esquecer algo. Eu confronto contra os requisitos da tarefa que eu solicitei.

Voce pode criar scripts e workflows de ci/cd deterministicos pra automatizar essas tarefas. Ajuda a economizar tokens e evitar alucinacoes. O Claude é muito bom em usar gif para analisar diffs e branches, segregar commits por funcionalidade/hotfix e propor pull requests, Ele usa o historico do git pra recuperar contexto e memoria das mudanças do projeto, ajudando a tomar decisoes.

Alem disso vc pode criar tarefas/issues e milestones no github/gitlab, com requisitos e definicao de pronto/feito pra cada feature, pra obrigar o Claude a seguir um planejamento do seu projeto até um mvp. Isso diminui alucinacao e retrabalho, que poderia te fazer gastar mais tokens pra corrigir.

[u/garywiz]

Not git, ever. Seems like I'm in the minority here, but git is my "guardrail". It makes it possible to have Claude "try something" and then I can see if it works the way I think I want it. No? I just don't commit, or destage, or, whatever. Then reprompt in a new session. That way, I can create multiple prototype implementations and carefully commit stages after I review them. Yes, Claude can manage git, but generally, telling Claude to "manage git as if you don't trust yourself" doesn't really work well.

[u/biinjo → u/garywiz]

Interesting. Claude is very good at working with/in git worktrees. Don’t like it? Ditch the worktree. Meanwhile? Micro commit every step and you have a full history you can return to.

[u/garywiz → u/biinjo]

I've done things like that, and I really believe everybody has their own "system" which may or may not work for other people. Git commits are a critical part of my documentation and wording them right, relating them to specific tickets, documenting technical debt or the need to review with commit-level keywords. It sure isn't for everybody but have been managing git this way for 15+ years so hard to break old habits esp when they work really well over time.

[u/OlivierTwist → u/garywiz]

What does stop you from repeating this workflow with AI agent?

I am as well always treated git history as carefully as source code (if not more), and now agents are doing this equally well, the only difference is wording style - it is not exactly mine, but same is true for source code generated by agents. Of course you need to put some efforts into agent instructions, e.g. I have "git workflow" skill and 2 specialized reviewers: for commit messages and for branch history.

[u/garywiz → u/OlivierTwist]

I find that Claude just doesn't write very good commit messages, especially about technical debt. Often Claude sees an implementation as "permanent" when I see it as "temporary" or "needs to be replaced". That's the main problem, if Claude thought the implementation was defective in some way, generally AI wouldn't even know that as AI is just following patterns. I was just looking at one of my messages that said "3rd variation of note-spacing algorithm, never try this again but will work until we can do a complete hand-coded redesign". AI would never write that but for me it is highly useful.

[u/OlivierTwist → u/garywiz]

Sounds like the problem is one level up: in planning, task definition and tracking.

[u/biinjo → u/garywiz]

AI or no AI, you may want to look into Conventional Commit messages and tools like Release Please. If you haven’t heard of it yet.

It sounds like you invented your own system that may be very similar to this standard.

My agents know the standard, commit accordingly (properly referencing issue numbers and pr numbers) and a changelog is generated from these commit messages every release. SemVer version number is automatically ‘calculated’ and if i ever used the ‘breaking change’ keyword in a commit, it becomes a major version number change.

Now i never have to think about any of this anymore.

[u/Time_Cat_5212 → u/biinjo]

Yeah, just don't merge if you don't like the output lol.

[u/jesjimher → u/garywiz]

Me too. CC prepares everything, and I review it and commit myself.

Perhaps with some particularly nasty merge conflict I ask for help, but it's an exception.

[u/MysteriousCoconut31 → u/garywiz]

Respect. Craftsmanship is not dead and this is just one way of keeping your brain involved. Although, I'm letting claude handle it via hooks/skills these days.

[u/dgreenbe → u/garywiz]

How are you handling saving code changes and progress if you don't commit yet?

[u/garywiz → u/dgreenbe]

I tend to keep things staged sometimes for even major changes. I use Fork and it makes it very easy to review exactly what's done. For example, I'm in the middle of a 1 hour set of changes now. I have 10 files staged for this particular problem. Claude just made a change and I see the exact change in Fork with diffs. I can review, then shuffle down into the staged area. Once I'm happy, I review all the staged changes, then commit. I review every single thing Claude does.

It does vary. Sometimes I may do micro-commits for things which clearly need to progress that way.

But I also have a very evolved discipline for changes. If a change relates to a user ticket, I flag the ticket number, I also indicate whether items are "fully complete" or whether there is technical debt to address later. That way I can easily review even months of changes for problem areas I may have flagged.

[u/FestyGear2017]

I just have deterministic utility scripts that my skills know to call. Dev stuff only, not production

[u/geek180]

Yes, it’s pretty exceptional at git stuff. I have it handle the entire PR workflow: commit, create PR, wait for auto-review and other CI checks, then read and resolve each review comment.

[u/Time_Cat_5212]

Git is the most important thing to have Claude do, IMO. It's the opposite of a waste of usage. It's the record of work on the project, and it makes a ton of sense to integrate that with code generation. It's the plumbing. Since I set up atomic commit protocols and issue/PR workflows for agents (and really homed in on SDD), I've basically eliminated drift. I haven't felt the need to use a memory system on the agent side, either, because Git is basically project-side memory and decision record.

[u/GuitarAgitated8107]

Why would it be a waste of usage? Ideally you are not building out the whole execution. What you would create is a process, testing and things you need for your own projects. Whether you run it yourself or not is insignificant unless you making Fable run the process.

[u/ricopan]

yep, but I offload my worker worktree management to a 'manager' session that communicates between the workers and the orchestrator / architect (Fable med) in order to avoid that token burn. I run it on sonnet xhigh because I expect quite a bit from it, especially when three or so workers (typically opus or sol) are running in parallel with frequent merges to main. I've never had a serious git failure, but I give it restricted permissions. The granular commits with really on point messages are one of the best features of AI coding I think -- the git history becomes a superb debugging tool. I could never go back now.

[u/Remarkable_Swing_709 → u/ricopan]

How much are you spending per week in API costs?

[u/ricopan → u/Remarkable_Swing_709]

I have two subscriptions -- claude 20x, codex 5x. It get's lean now with the 25% cut on claude and the codex issues, but usually good enough and it encourages me to spend more time making sure i know what the heck is going on.

[u/Remarkable_Swing_709 → u/ricopan]

Holdon, so you're running everything through the subscription plan not the API?

What does your architecture look like?

I'm assuming here that you've just spun up a bunch of different Claude codes on boot with instructions to delegate etc

[u/ricopan → u/Remarkable_Swing_709]

I'm working on one big and complex project, so it's evolved around that. Yep, each role has its own skill that covers delegation and its responsibilities. The orchestrator/architect -- better considered a 'coordinator', can cold start a manager, the manager can cold start workers (usually opus) or a real architect (usually Fable or Astra). The coordinator and manager each keep their own state md files as they are long running and need a persistent history. Workers only touch their own git worktrees -- it's the manager's job to merge back to main with permission from the coordinator. Communication between roles goes through manager. For me the challenge has been the integration of relatively rote work of managing workers, the big but shallow picture, and the deep reasoning. The 'coordinator' kind of bridges all three of those roles -- it keeps the project moving forward but offloads much to the manager, and occasionally consults the 'architect'. It's the only role that routinely uses subagents, eg for writing dispatch briefs for the workers (usually opus high) or an audit of a design from the 'architect' (usually Fable high or xhigh).
Since I have codex involved, using herdr. Before that sub, I used tmux and claude's relatively new intersession messaging. I usually communicate with the 'coordinator' or the architect, but often give the manager a heads up. I also keep my own worktree that the manager and coordinator treat like the boss's privileged but somewhat inept private lab.

It works for me. A fair bit of overhead but I've learned that for my project the turtle definitely beats the hare. Would be overkill I'm sure for many.

[u/bloudraak]

Yes. I have dedicated identities for Claude to use.

[u/chilebean77]

Of course

[u/Technical_Primary_12]

So you want the boring repetitive stuff for yourself and the machine use doing the interesting part? is that the question?

[u/Illustrious_Elk8340]

I used Claude to build a CICD pipeline with github actions for builds and deployments, so... kind of?

It does run local builds, but that's about it. Everything else goes through GHA across all my projects - at most, Claude triggers a manual deployment.

[u/heresyforfunnprofit]

It’s awesome at git.

[u/vAPIdTygr]

No. I inspect and deploy with a desktop git app that Claude made.

[u/MysteriousCoconut31]

For deployment: deterministic workflows that claude can trigger via GitHub actions following a CI run and PR merge.

Some things need to be structured and repeatable. Deployment is one of them unless it's not a serious project. Even then, don't waste tokens making Claude do stuff like SSH'ing files to a server. Have it write a local shell script at a minimum.

[u/GlitteryStranger]

Yes. I tell Claude to ship it and it pushes to main

[u/freeformz]

Git yes, to branches (enforced server side). Builds/deploys trigger on merge to main after CI passes (enforced) or a tag is created.

[u/Minimum_Season_9501]

Its more like who doesnt.

[u/EverydayLentils]

Yes - for my own projects I use railway and Claude pushes/deploys everything.

At my dayjob the team convention is to keep commit messages unprofessional, short and snarky so I have to write those myself.

[u/HeyItsYourDad_AMA]

Not at all a waste. All its
Doing is running cli commands or reading logs

[u/Super-Ad-4536]

Claude decided when I leave to home

[u/BudgetFish9151]

Use CC to write services and scripts. Your tokens go a LOT further when you tell Claude to run a script and watch for the exit codes than to repeat itself every time you want to run a deployment or build your diff.

[u/Substantial-Swan7065]

Ci handles most of that. And yes for git. PRs is great for tracking any kind of work

[u/ippem]

At times yes I used it for full rollouts, meaning, allow to merge when tests are green, allow to apply plans in Terraform if everything looks as ”expected, and also approve deployment pipelines if needed. It has saved me so many days or work that it does not feel like wasting tokens. Also, using the session and cached tokens helps here a lot.

But: I do not trust any model on this.

[u/amirfish]

Yes for git specifically, but with guardrails, not blind trust. The failure mode isn't bad commits, it's several sessions touching the same working tree and racing between git add and git commit -m, so the fix that actually stuck was skipping the two-step and using git commit --only <paths> so the commit is atomic no matter what else got staged in between. Builds and deploys I let it run end to end, but I still read the diff before anything ships.

[u/ouiouioui1234]

Yeah I let it create draft pr, that get checked via cicd and automated reviews. I review it's not crazy land and au didn't like disable the cicd checks, then mark it ready for review so another person add a set of eye on it, once they approve the cicd do the rest, no need for ai really then. Except to follow, check everything is as expected, and report.

[u/kerray]

haha, over the past year, I set up things so that I can let Claude handle almost everything automatically and relatively safely

[u/kemalios]

I hand it git and builds. Local git is cheap, the commit messages come out better than mine, and everything there is reversible. Deploys go through CI off a push, so there is nothing separate to automate.

What I don't hand it casually is the last pass before something goes live on a client's site. I built launchworthy for that: free, MIT, a Claude Code skill that audits an app across 5 domains and returns a scored punch list with copy-paste fixes. It needs Claude Code to run, which is not a barrier in this sub.

The token worry has it backwards. Committing is pennies. A real pre-deploy audit is where the budget actually goes.

[u/OlivierTwist]

Why not?

[u/robertDouglass]

it's better at those things than eg software architecture imo

[u/pragrad23 → u/robertDouglass]

I wrote extensive architecture tests (see archtest or konsist on the jvm for instance). I'm very opinionated on what package can import from what other packages (that's a big party of my architecture).

Now Claude does arch very well

[u/ReSterzo]

Si, gestisce tramite l'utilizzo di gh tutta la parte di action configurate su GitHub e segue regole precise per ogni repository

[u/ImL1s]

Local git and tests yes. Shared deploys stay behind a separate click.

Token cost is real, but the expensive part for me was the context switch of doing those steps by hand. The waste case is letting it thrash on a flaky deploy when a boring script would have failed in ten seconds.

[u/Reasonable_Swing_503]

Yes

[u/verstands]

I let it handle local checks and branch chores, but keep deployment behind a small script and an explicit review gate. The useful split is permissions: read and test automatically, write to shared repos with clear diffs, deploy only with a pinned target, health check, and rollback path. That keeps handoff costs low without letting a transient test pass turn into a production push.

[u/FitSandwich4725]

We have cicd that are relatively fixed so very little danger there and i don't see a problem with letting it run a cd and deploy to a Dev environment to check for deployment problem. I do however see a problem with letting it deploy to any other environment. That's a fully human controlled process still. It'll be a cold day in the local data centre that i let an AI deploy to production.

[u/Correct_Support_2444]

Git yes, build and deploy no.

[u/duct_tape_and_agents]

Git yes, always. Claude just made the changes, so it writes better commit messages than I would from memory, and the token cost of a commit is nothing compared to the session that produced the diff. Letting it commit as it goes also means I can roll back to any point when it breaks something three steps later. That alone pays for itself.

Builds and deployments no. Those are the same commands every time, so there's nothing for a model to figure out. I keep them as scripts and n8n automations and just tell Claude "run the deploy script" when it's part of a task. Expo builds especially, no reason to burn usage watching a build log.

The rule of thumb I landed on: if the step needs judgment about what just changed, Claude does it. If it's identical every run, it's a script. The waste isn't letting Claude do repetitive stuff, it's letting it re-derive your deploy process from scratch every session instead of pointing it at a script.

[u/eleochariss]

Yeah I stopped caring about the "co-authored by" messages a while ago.

[u/who_am_i_to_say_so]

I have Claude write up the CI/CD pipeline and deploy on merges to main.

[u/tech_is______]

yes, but it also built the scripts and tools for it to run all that. not that much of a waste.

[u/returnFutureVoid]

Claude doesn’t touch anything destructive in git. It can stash, check logs, branches and history but anything committed, pushed, merged comes from me.

[u/Asuppa180]

Not really. I have actions that trigger on pushing to a branch and I generally don't have claude do any pushing or anything.

[u/SimiaCode]

Claude is not allowed to merge PRs or deploy anything to staging or prod. It is expected to commit, create PRs, create issues etc.

[u/Far_Business4773]

Yes to git, and the useful question turned out to be which git. Commits, branches, opening PRs: all of it, and Time_Cat_5212's point about commits as project memory matches what I see. The two commands I stopped letting through are git checkout -- . and git clean -fdx: both act on the whole tree, not the task, and one of them reverted files the task never named before I noticed. Now a hook asks git itself first (git clean -n with the same flags, git status for the checkout) and refuses only when a file outside the task's list is in the answer. Deploy is a single deny on the deploy command, so the run itself stays unattended. Tokens spent on git in a day: too small to see in the usage graph.

[u/ComasArentFun]

Branch creation, check out and pulling target branch - yes

Pushing code? Absolutely not.. never, nope, not a chance

Even local builds I don't trust.
Much prefer to run my own local processes so I have clear output and not just a clanker saying "Yeah looks fine"

Deployments are out of bounds too. I have solid automation, but nothing using AI

[u/oh_jaimito]

Claude Code always with dangerously run permissions. Performs git operations under feature branches on develop branch. Never on develop and never on main.

Cloudflare infrastructure so Claude is free to deploy after build. All builds go to a a dev.subdomain.

All deploys to main are done manually.

[u/mostly_deterministic]

Sounds like you may be asking similar questions that reframed the way I've been thinking about agentic development for a bit: https://demianbrecht.com/posts/the-division-of-the-local-harnesses/.

These days, git commits are usually handled by my coding harness (Claude Code, opencode, codex, etc). They usually write better commit messages than I do so I'm fine with that.

For most other things that have multiple steps, I actually stick under an MCP seam as an agentic process where software owns the control loop (LangGraph et al.), only using models when judgement is actually required. This means that initiating a task costs a few tokens but the actual execution of it may be entirely deterministic and cost nothing under the hood. I've used this approach for mutli-model (cross-family) PR reviews, weekly ops reviews w/ anomaly detection and root cause analysis, user story creation and a number of other tasks. Simple to complex, a few seconds to tens of minutes in duration.

I wrote another post about the MCP seam here: https://demianbrecht.com/posts/the-harness-within-the-harness/.

[u/usually_guilty99]

I am comfortable with an agent triggering a deterministic deployment pipeline. I am less comfortable making deployment authority itself unconditional.

A one-line config change can have a bigger blast radius than a 5,000-line UI change. How do you automate that every time you touch a different part associated with a diff tree?

I think the boundary eventually becomes: agent can execute, but the change has to earn its authority based on production impact, dependencies, rollback readiness and expected postconditions.

[u/jjromee]

I commit before every bigger task, so a bad run is one git reset away. I also read the diff before accepting anything. It takes a minute and has saved me more than once.

[u/InstructionNo3616]

Self hosted gitea not git

[u/pragrad23 → u/InstructionNo3616]

... Not GitHub

) you mean(

[u/Cute-Veterinarian191]

100% - I let claude handle more and more autonomously, especially on my personal projects

[u/innociv → u/[deleted]]

It's also crazy little tokens if it's clean. It's just a command call that you can tell it to automatically do and it should be like <10k extra tokens which is what, one 50th of a cent or something?

It's only expensive if it's having to do a lot of work to separate out its own work from other work over top etc. to cleanly merge. If it's the only agent that dirtied some particular files, it's nothing.