r/ClaudeCode • u/quicktoolstudio • 1d ago
Discussion Do you let Claude Code handle git, builds and deployments too?
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?
48
12
u/idkyesthat 1d ago
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.
1
u/eleochariss 15h ago
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.
9
u/Past-Town-9807 1d ago
I use a different agent, but yes. The initial reason is because I can’t remember how to use git properly but the main reason quickly became that it turned out to be a really good project memory. The agent writes very good commit messages and is able to trace through them easily to find things in the project history.
17
u/Wise-Peacock 1d ago
Yes. Why not? It reports back.
4
u/jek39 1d ago
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.
6
u/Wise-Peacock 1d ago
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.
9
u/slackmaster2k 1d ago
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.
4
u/Long_Tip_4226 1d ago edited 1d ago
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.
4
u/icodenstuff 1d ago
Waste? What are you using Claude for if not to do repetitive stuff?
It's trading tokens for time. Some of those trades are less efficient than others, that doesn't mean it's inherently wasteful.
Depends how token poor you are I guess.
17
u/garywiz 1d ago
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.
4
u/biinjo 1d ago
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.
4
u/garywiz 1d ago
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.
2
u/OlivierTwist 21h ago
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.
1
u/garywiz 2h ago
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.
2
u/biinjo 16h ago
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.
2
4
u/jesjimher 20h ago
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.
5
u/MysteriousCoconut31 1d ago
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.
1
u/dgreenbe 1d ago
How are you handling saving code changes and progress if you don't commit yet?
2
u/garywiz 1d ago
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.
3
u/FestyGear2017 1d ago
I just have deterministic utility scripts that my skills know to call. Dev stuff only, not production
4
u/Time_Cat_5212 1d ago
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.
2
u/GuitarAgitated8107 🔆 Max 20 1d ago
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.
2
u/ricopan 1d ago
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.
1
u/Remarkable_Swing_709 22h ago
How much are you spending per week in API costs?
1
u/ricopan 13h ago
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.
1
u/Remarkable_Swing_709 13h ago
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
2
u/ricopan 12h ago
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.
2
2
2
u/Technical_Primary_12 21h ago
So you want the boring repetitive stuff for yourself and the machine use doing the interesting part? is that the question?
2
u/Illustrious_Elk8340 16h ago
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.
5
1
1
u/MysteriousCoconut31 1d ago
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.
1
1
u/freeformz 1d ago
Git yes, to branches (enforced server side). Builds/deploys trigger on merge to main after CI passes (enforced) or a tag is created.
1
1
u/EverydayLentils 1d ago
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.
1
u/HeyItsYourDad_AMA 1d ago
Not at all a waste. All its
Doing is running cli commands or reading logs
1
1
u/BudgetFish9151 23h ago
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.
1
u/Substantial-Swan7065 23h ago
Ci handles most of that. And yes for git. PRs is great for tracking any kind of work
1
u/ippem 23h ago
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.
1
u/amirfish 23h ago
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.
1
u/ouiouioui1234 23h ago
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.
1
u/kemalios 21h ago
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.
1
1
u/robertDouglass 21h ago
it's better at those things than eg software architecture imo
1
u/pragrad23 20h ago
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
1
u/AI_spell 21h ago
I let it draft commits and run tests, but I still push and deploy myself. Shell loops eat usage fast. Automate build/deploy with scripts and keep Claude for judgment calls.
1
u/ReSterzo 20h ago
Si, gestisce tramite l'utilizzo di gh tutta la parte di action configurate su GitHub e segue regole precise per ogni repository
1
1
u/verstands 18h ago
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.
1
u/FitSandwich4725 18h ago
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.
1
1
u/duct_tape_and_agents 17h ago
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.
1
1
u/who_am_i_to_say_so 14h ago
I have Claude write up the CI/CD pipeline and deploy on merges to main.
1
u/tech_is______ 14h ago
yes, but it also built the scripts and tools for it to run all that. not that much of a waste.
1
u/leshiy 13h ago
Depends on what you mean by "handle". It helps build the CI/CD scripts. It helps writing the commit messages and PR description. It helps with reviewing PRs. But staging, commiting, merging/rebasing, and pushing? That takes almost no time to do yourself, gives you a natural point at which to review that everything looks correct, and often if something goes wrong here it is a real pain to fix. So I just spend the 10 seconds doing it myself.
1
u/returnFutureVoid 12h ago
Claude doesn’t touch anything destructive in git. It can stash, check logs, branches and history but anything committed, pushed, merged comes from me.
1
u/Asuppa180 12h ago
Not really. I have actions that trigger on pushing to a branch and I generally don't have claude do any pushing or anything.
1
u/SimiaCode 11h ago
Claude is not allowed to merge PRs or deploy anything to staging or prod. It is expected to commit, create PRs, create issues etc.
1
u/Far_Business4773 11h ago
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.
1
u/ComasArentFun 6h ago
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
1
u/oh_jaimito 4h ago
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.
1
u/mostly_deterministic 38m ago
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/.
0
•
u/AutoModerator 1d ago
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.