Git, the GitHub CLI, and CI are where Claude Code saves time most visibly, because most of the work there is typing commands, reading logs, and waiting, which is exactly what an agent can do for you.
This is part six of a series that walks through all 50 Claude Code tips in YK Sugi's claude-code-tips repo. It groups six tips about Git, GitHub, and operations: numbers 4, 13, 14, 15, 36, and 27. They run from the smallest job (one commit) to the most time-consuming (a red CI run with no obvious cause).
The principle throughout: let Claude do the legwork, and keep the high-risk steps such as push and merge for yourself.
How do you hand Git and the GitHub CLI to Claude?
Just ask Claude to do it: committing (so you never write a commit message by hand), branching, pulling, and pushing. A sensible permission split is to allow pull automatically but not push, because push is riskier: a pull that goes wrong doesn't contaminate origin.
With the GitHub CLI (gh), the habit most worth building is creating draft PRs. Claude handles the whole PR creation process at low risk, and you review everything before marking it ready for review. gh is also more powerful than most people assume: it can send arbitrary GraphQL queries. For example, to find exactly when a PR description was edited:
gh api graphql -f query='
query {
repository(owner: "...", name: "...") {
pullRequest(number: ...) {
userContentEdits(first: 100) {
nodes { editedAt editor { login } }
}
}
}
}'Claude runs it and returns the edit history as a table, one row per edit with the time and the editor. You don't need to know GitHub's GraphQL schema; describing what you want to know is enough.
How do you turn off Claude's attribution in commits and PRs?
By default, Claude Code adds a Co-Authored-By trailer to commits and an attribution footer to PR descriptions. To remove both, add this block to ~/.claude/settings.json:
{
"attribution": {
"commit": "",
"pr": "",
"sessionUrl": false
}
}Setting commit and pr to empty strings removes the attribution text entirely. This replaces the older includeCoAuthoredBy setting, which is now deprecated. sessionUrl is a separate flag (default true): when you commit or open a PR from a cloud or Remote Control session, Claude Code adds a Claude-Session trailer to the commit and a session link to the PR description. Set it to false to drop that link. Whether to turn these off is each team's call, but you should at least know the keys exist.
How do you run several Claude Code sessions without losing track?
When you run multiple Claude Code sessions, staying organized matters more than any technical setup, git worktrees included. The advice is to focus on at most three or four tasks at a time.
The method in the repo is called a "cascade": every time you start a new task, open a new tab on the right. Then sweep left to right, oldest task to newest, over and over. The general direction stays the same, except when you need to check on a specific task or respond to a notification.
A typical layout: the leftmost tab is a permanent one running the voice transcription system; the second sets up a Docker container; the third checks disk usage; the fourth works on an engineering project; the fifth (the active one) is writing this very tip. It sounds simple, but I find the "three or four tasks" limit is the hard part to follow: opening another tab is easy, remembering which tab is waiting on you is not.
How do git worktrees help with parallel work?
When you are doing several things at once in one project and don't want them to collide, git worktrees are a great option. You can just ask Claude Code to create a git worktree and work there, without remembering the syntax. The basic idea: a worktree is a branch plus its own directory.
Without worktrees, your project folder can only sit on one branch at a time, so main and feature-branch-1 have to be worked on in turn. With a worktree, you keep working on main (or any branch) in the original folder while working on feature-branch-1 in a new one.
Worktrees layer on top of the cascade above: one tab per task, and any task that touches code gets its own worktree. A tip from part three applies here too: ask Claude to open that worktree in GitHub Desktop to review changes, since you usually haven't opened Claude Code in the new folder.
Waiting on long jobs with manual exponential backoff
When waiting on long-running jobs such as Docker builds or GitHub CI, ask Claude Code to check the status with growing intervals: one minute, then two, then four, and so on. Exponential backoff is a familiar technique in software engineering; here the AI simply does it by hand instead of in code, and it works pretty well. The agent keeps checking and tells you once the job is done.
For GitHub CI specifically, gh run watch exists but prints a continuous stream of lines, which wastes tokens. Manual backoff with a command like this is more token-efficient:
gh run view <run-id> | grep <job-name>It is also a technique that works anywhere you don't have a dedicated wait command. Each check costs a few lines of output instead of a log stream pouring into your context.
Running bash commands and subagents in the background
When a bash command in Claude Code runs longer than expected, press Ctrl+B to move it to the background (tmux users press it twice, since Ctrl+B is tmux's prefix key). Claude Code knows how to manage background processes and read their output later. Meanwhile it can use the backoff method above to watch progress, or get on with something else entirely.
Claude Code can also run subagents in the background. For a long research job, or an agent that checks on something periodically, it doesn't have to occupy the foreground; just ask Claude to run that agent or task in the background. Beyond backgrounding, subagents help break a big job down: for a huge codebase you need to analyze, ask Claude to spawn several subagents that analyze it in different ways, or each look at a different part of the codebase, in parallel.
You customize subagents just by asking: how many, background or foreground (ask, or press Ctrl+B), and which model (Fable, Opus, Sonnet, or Haiku depending on how hard each piece is). If you say nothing, subagents inherit the main conversation's model, so for simple work like scanning files, naming a smaller model is the easiest saving available.
Using Claude Code as a DevOps engineer
This tip gets its own section because of how well it works. Whenever GitHub Actions CI goes red, hand the link to Claude Code and say "dig into this issue, try to find the root cause." The first answer is sometimes shallow, but keep asking: was it caused by a particular commit, a particular PR, or is it a flaky issue? Wading through piles of logs by hand is painful, and Claude Code handles most of it.
The workflow is packaged as a /gha slash command: run /gha <url> with any GitHub Actions URL and it investigates the failure, checks for flakiness, identifies the breaking commit, and suggests fixes. The skill lives in the repo's skills/gha folder, or you can install it through the dx plugin.
Once you know what went wrong, go back to the earlier tips: open a draft PR, check the output, have Claude verify its own work (part five), and only then turn it into a real PR with the fix. To me this is where Claude Code pays for itself fastest on a small team: a red CI run that used to cost an afternoon of log reading becomes a handful of questions.
Which step should you hand to Claude first?
Start with draft PRs and /gha (or the "find the root cause" prompt), because both are low risk: Claude does the work and you approve it before anything reaches anyone else. Worktrees, multiple tabs, and background subagents come next, once you are comfortable keeping three or four tasks in your head at once.