What it is
Git is a distributed version control system. Every copy of a repository holds the full history, so developers can commit, branch and compare changes on their own machine and share them later. It was created by Linus Torvalds in 2005 for Linux kernel development and is now the standard for source control. It is free and open source.
Its model is simple to describe: commits are snapshots linked to their parents, and branches are lightweight pointers to commits. On top of that sit merges, rebases, tags and remotes, which let teams work in parallel and bring the work back together with a full record of who changed what.
Git also has hooks, small scripts that run at points such as before a commit or a push, and worktrees, which let one repository have several working folders checked out at once. Those two features are where a team's rules can be enforced rather than just written down. Git runs on macOS, Linux and Windows.
How I use it
- Every product I run lives in Git, and the history is the audit trail: Rental Pilot's API, web app and phone app and Lend Pilot on AWS CodeCommit, and this site on GitHub.
- The API and phone app are trunk-based, pushed straight to main; the web app and this site go through pull requests.
- Pre-push hooks refuse a push from the wrong branch or a dirty tree.
- Deploy scripts refuse to run unless the checkout is exactly the tip of origin/main with a clean tree, because they ship what is on disk and a deploy should ship what was reviewed and nothing else.
- When several AI coding sessions work at once, each gets its own git worktree, so none of them can overwrite another's files.
- Every push to the API's main branch deploys to the test server through CodePipeline and CodeDeploy, and the build log shows coding sessions live with numbers regenerated from git.
Git is the right tool for any code that matters, but the tool alone does not make a process. I treat Git as the control point for everything that ships. If it is not committed, pushed and on main, it does not go to production. That rule has to hold for me and for the AI coding agents that work beside me, so I enforce it with hooks and scripts instead of trusting memory.
Questions
How do you stop untested or uncommitted code reaching production?
The deploy scripts check Git before they do anything. If the checkout is not exactly the tip of origin/main with a clean tree, they refuse to run, so only committed, pushed and reviewed code can ship. Pre-push hooks also block pushes from the wrong branch or with uncommitted changes.
How do you keep several AI coding agents from clashing?
Each agent session works in its own git worktree, a separate working folder on the same repository. They cannot overwrite each other's files, and their work comes back together through Git like any other change.
Trunk-based or pull requests?
Both, chosen per product. Rental Pilot's API and phone app are trunk-based, pushed straight to main and deployed to the test server automatically. The web app and this site go through pull requests.