Git and GitHub for AI Builders: Version Control as Your Safety Net
Published on 07.05.2026
Git and GitHub Are Not the Same Thing
TLDR: Git is local software that tracks changes on your machine. GitHub is a cloud hosting service. Conflating the two is the most common mistake people make before they understand version control at all.
Summary: Pawel opens this third entry in his Basics series with a clarification that trips up almost everyone: Git and GitHub are separate things. Git was written by Linus Torvalds in 2005 and runs entirely on your machine, tracking snapshots of your project in a hidden .git folder. It works whether or not you ever touch the internet. GitHub is Microsoft-owned cloud storage for those repositories. It makes them remotely accessible and shareable, but it is not Git itself.
This distinction matters because a lot of people assume using version control means creating a public repository on a platform they don't trust. That is not true. You can run Git locally and never push anywhere. Or you can push to GitLab, which has full CI/CD built in and supports self-hosting. Codeberg is nonprofit, GDPR-native, and explicitly does not train AI models on your code, which matters if you are in Europe or care about data sovereignty. Forgejo lets you self-host entirely. Bitbucket plugs into the Atlassian ecosystem.
All of these speak the same Git command language. The choice of platform is purely about where your code lives, not about any incompatibility in workflow.
Pawel himself uses GitHub because his AI tools, Claude Code in particular, integrate well with it. That is a legitimate reason. But the framing here is important: choose based on your actual constraints, not out of assumption.
Key takeaways:
- Git is local software; GitHub is one of several cloud hosting options
- Codeberg and Forgejo are real alternatives for privacy-conscious or self-hosting use cases
- Your choice of platform does not change a single Git command
Why do I care: This clarification should be in every onboarding document for developers. The Git/GitHub conflation causes people to either skip version control entirely or get locked into a platform they resent. The fact that you can run Git with zero network access, on a machine nobody else can see, is architecturally important. Private repos on any platform are normal professional practice, not a confession.
Digital Thoughts by Pawel Jozefiak
Why Version Control Becomes Non-Negotiable With AI Agents
TLDR: Running an overnight AI agent without version control means waking up to a broken system with no map back to working. Commit discipline turns unknown disasters into traceable investigations.
Summary: Pawel's personal turning point is specific and convincing. He had been casual about Git for years. Then he started running an agent overnight, and one morning woke up to something broken across twelve files in three directories. No commits meant no history, and no history meant no way to understand what had changed. The agent had touched everything and left no trail.
His fix was to build commit discipline directly into the agent itself. Now it commits after every meaningful action. When something breaks, he reads the history, sees exactly what changed in what order, and rolls back to the last clean state in under ten seconds. The history is navigable, not just a backup. He draws a clean distinction here: saving a file versus saving a timeline. A timeline makes mistakes into investigations. Without one, they are just disasters.
This framing should land differently for people who think of version control as a formality. When an AI agent is making decisions and modifying files autonomously, the commit log is the audit trail. It is the only record of what the system was thinking, sequentially, over time. Without it you are debugging in the dark with no landmarks.
Key takeaways:
- Overnight agent runs without commit discipline produce unrecoverable messes
- Version control is a navigable timeline, not just a backup mechanism
- Building commit discipline into the agent itself solves the accountability problem
Why do I care: I have seen this exact failure mode in human-only projects, and it is worse when the agent is autonomous. The audit trail argument is underrated. People treat commits as admin work when they are actually the closest thing to a structured log that most codebases have. If you are running any kind of autonomous build process, treating commits as optional is genuinely reckless.
Digital Thoughts by Pawel Jozefiak
Setting Up Your First Repository, Step by Step
TLDR: The entire setup takes less than ten minutes: install Git, configure your name and email once, run git init, make your first commit, and optionally push to a remote. That is the whole foundation.
Summary: Pawel walks through the setup with zero assumed knowledge. On Mac, git --version tells you if Git is already installed. If not, the installer is at git-scm.com or brew install git handles it. On Windows, the installer from git-scm.com includes Git Bash as a terminal. One-time global config sets your name and email for commit attribution. Then git init in your project folder creates the .git directory that holds everything.
The first commit is two commands: git add . to stage everything, and git commit -m "Initial setup" to save the snapshot. Running git log confirms it worked. Connecting to a remote is optional but recommended: create an empty repository on GitHub, copy the URL, run git remote add origin with the URL, and git push -u origin main. After that first push, future pushes are just git push.
The .gitignore section deserves attention. A file named .gitignore in your project root tells Git which paths to never track. The critical entries for AI agent projects are .env and any secrets folder. API keys committed to Git and pushed to a remote are visible in the history even after you delete the file. Pawel states this directly: if you accidentally push a secret, change the key immediately. The history is permanent.
Key takeaways:
- The entire initial setup is five commands; there is no reason to delay
.gitignoremust be created before your first commit if you have.envfiles- A committed secret is visible in history forever, even after deletion
Why do I care: The .gitignore point is not optional safety advice. It is a real incident waiting to happen. I have seen teams spend days rotating credentials after a developer's first-ever commit included an API key. The tooling around secret scanning is getting better, but the right behavior is to never commit secrets in the first place. If you use any AI coding tool that sets up environment variables, the .env file must be in .gitignore before anything else happens.
When to Commit and How to Write Messages That Mean Something
TLDR: Commit before anything big, after anything that works, and before you sleep. Write messages specific enough that a future debugger, human or AI, can understand what changed and why without any other context.
Summary: Most beginners commit too rarely and write messages that are useless. Pawel's framework is straightforward. Commit before handing a big task to an AI agent, because if it goes sideways you want to be one git reset --hard HEAD away from a clean state. Commit after each thing that works, no matter how small. Commit before going to bed if an agent is running overnight. On active architecture work, he commits every fifteen to thirty minutes.
The message quality argument is where this section gets interesting. Pawel writes every commit message as a note to a future debugger who has no other context. That debugger might be him, a collaborator, or an AI agent. All three need the same thing: specific, honest context about what changed and why. "Add rate limit guard to external API calls" tells you something. "wip" tells you nothing.
The reason this matters specifically for AI agents is that Claude Code's first move in a debug session is often git log --oneline. It reads the recent commits to build a model of what happened. Useful messages give it a map. Vague messages make it start from zero every time. Good history accelerates the agent's work on subsequent sessions. Messy history is technical debt that compounds silently.
Key takeaways:
- Commit before big agent tasks so you can roll back in one command
- There is no such thing as committing too often; frequent small commits are correct
- Commit messages are documentation read by future humans and AI agents alike
Why do I care: The framing of commit messages as "notes to a future debugger" is exactly right, and it becomes more true the more you use AI coding tools. An AI agent that reads your history builds a working model of your codebase's recent evolution. That model is only as good as the history you gave it. Treating commit messages as an afterthought is essentially making your AI assistant less useful on every subsequent session.
Digital Thoughts by Pawel Jozefiak
Branches, Pull Requests, and Worktrees for Parallel Agent Work
TLDR: Branches isolate experiments without affecting your main working code. Worktrees let multiple AI agents work on different branches simultaneously in separate directories, with zero interference between them.
Summary: For solo work, the simplest workflow is committing directly to main. Branches are worth introducing when you are testing something big or uncertain. A branch is a separate line of development: you create it, work and commit freely, then either merge it back if things went well or delete it cleanly if they did not. Pawel uses this specifically when handing experiments to an AI agent. The agent gets a branch, builds and commits freely there, and the results get reviewed before anything touches main.
With a team, branches and pull requests become mandatory. No one pushes directly to main. The PR process is where review happens, where bugs get caught before merge, and where context gets documented. Pawel has started creating PRs even when working solo, using the description field to explain why something was built, what problem it solves, and what approaches were rejected. That context is genuinely useful later, both for himself and for AI agents reading the repository to understand decisions.
Worktrees are the advanced feature specifically useful for parallel agent builds. A worktree is a separate folder linked to the same repository but checked out to a different branch. Each has its own working directory and independent state. Running two Claude Code instances at the same time, one on main and one on a feature branch, is clean and interference-free with worktrees. The commands are git worktree add ../feature-branch -b feature/name main to create one and git worktree remove to clean up.
Key takeaways:
- Branches give AI agents a safe space to work without touching main
- PR descriptions, even for solo work, serve as architecture documentation
- Worktrees enable genuinely parallel agent builds with separate working directories
Why do I care: The worktrees section is where this post earns its place in the advanced conversation. Most version control tutorials stop at branching. Worktrees are what you need once you are actually running parallel agents, and the mental model shift from "one working directory" to "multiple working directories sharing one history" is the unlock. If you are running any kind of multi-agent system and have not tried worktrees, you are doing unnecessary context-switching.
Comparison of Claude Code, Codex, Aider and others
The Commands You Will Actually Use
TLDR: Ninety percent of daily Git work is eight commands. Knowing the difference between reset --hard and revert saves you from permanent mistakes once you start pushing to remotes.
Summary: Pawel closes with a reference list of the commands that cover most real work: git init, git status, git add, git commit, git push, git pull, git log, git diff, git show HEAD, git checkout -b, git merge, and git branch -D. These are the daily tools.
The distinction between git reset --hard and git revert is worth dwelling on. Reset rewrites history by removing commits entirely. If you have already pushed those commits to a remote, reset becomes dangerous because it creates divergence between local and remote history. Revert creates a new commit that undoes the previous one, leaving history intact. It is always safe. When in doubt, use revert.
Claude Code handles most of these commands automatically in normal sessions. You can tell it to commit with a meaningful message and it will. But understanding what the commands actually do means you can read what the agent is doing instead of watching it happen blindly. That reading comprehension is what lets you catch mistakes before they compound.
Key takeaways:
git reset --hardrewrites history and is dangerous after pushing;git revertis always safe- You do not need to memorize all commands, but you should understand what staged, committed, and pushed mean
- Claude Code runs these commands itself, but you need to understand them to supervise the agent
Why do I care: The reset versus revert distinction is the one that costs people the most when they get it wrong. Resetting pushed commits creates a broken state that requires a force push to fix, and force pushing to a shared branch is a way to lose other people's work permanently. The practical rule is simple: if the commit has been pushed, use revert. If it has not been pushed, reset is fine. Knowing this before you need it is the whole game.