Git-Native Workflows

Because Claude Code has real shell access, git isn't a bolted-on integration — it's the same git you'd run yourself, used the same way, with the same safety considerations.

Inspecting state before acting

Before making a change, checking git status and git diff clarifies what's already modified versus what's clean — useful context when a task starts mid-way through someone else's unfinished work, or when you want to confirm nothing unexpected is already sitting in the working tree. git log on a relevant file often answers "why is this written this way" faster than guessing — a commit message or an old PR description frequently contains the reasoning a code comment doesn't.

Writing commit messages from the actual diff

A commit message written by Claude Code is generated from the real, staged diff — not from a description of intent — which tends to produce messages that describe what actually changed rather than what was merely planned. Good practice (and worth stating explicitly in your CLAUDE.md if your team has a convention) includes a focused summary line and, where useful, a short body explaining why the change was made, not just what it touched.

Branching and pull requests

Creating a branch, pushing it, and opening a pull request follows the same pattern as a human contributor would, using the same CLI tools (git, gh, or whatever your platform provides). A well-written PR description references the actual diff and the reasoning behind it, and can pull relevant context from the conversation that led to the change — useful for reviewers who weren't party to that conversation.

Safety boundaries that matter here

Some git operations are easy to get wrong in ways that are hard to undo, which is exactly where a conservative default matters most:

• Force-pushing can overwrite someone else's work on a shared branch — treat it as something that needs explicit confirmation every time, never a default action.
• Resetting or discarding changes (git reset --hard, git checkout -- on uncommitted work) destroys uncommitted work with no undo. If there's unfamiliar state in a working tree — files that don't look like they were created by the current task — investigate before clearing it rather than assuming it's safe to discard.
• Amending or rewriting published history changes commits other people may have already pulled. Creating a new commit is almost always the safer default over amending an existing one, unless you're explicitly asked to amend and know it hasn't been shared yet.
• Skipping hooks or signing (--no-verify, --no-gpg-sign) bypasses checks that exist for a reason. If a pre-commit hook fails, the right move is fixing what it's flagging, not disabling it.

None of this means git operations need constant hand-holding — routine commits, branches, and diffs are exactly the kind of well-scoped, reversible action that's safe to allow broadly. It means the genuinely destructive subset of git commands deserves a different default than everything else, which is the same principle covered in permission modes applied to one specific, high-stakes tool.

Next: looking things up beyond the codebase itself.