Git Discipline for AI-Assisted Development: The AIC Way¶
Date: September 23rd, 2025 Author: Daniel Shanklin, Director of AI and Technology, AIC Holdings Tags: Git Workflows, AI Development, Team Productivity, Repository Management
Why Git Gets Weird When AI Joins Your Team¶
Here's what nobody tells you about working with AI coding tools: your Git workflow will break. Not slowly, not gradually - it'll break fast and hard within the first week.
AI tools like Claude Code can bang out 20 commits while you're grabbing coffee. They'll create branches for everything, generate pull requests that touch 47 files, and somehow always manage to conflict with that one branch your teammate has been working on for three days. Traditional Git practices, the ones that worked fine when humans were the bottleneck, suddenly feel like trying to direct airport traffic with a stop sign.
We've spent six months figuring out how to make Git work with AI instead of fighting against it. Turns out, the solution isn't working faster - it's working smarter.
When Your Repo Becomes a War Zone¶
You know that feeling when you come back from vacation and there are 47 new branches, half of them named things like "fix-user-auth-v2-final-actually-final"? That's what happens to your repository about two weeks after your team starts using AI tools regularly.
The problem isn't that AI is bad at Git - it's that AI is too good at Git. It'll happily create a new branch every time you ask it to "quickly fix that login bug," without considering that there might already be three other branches trying to fix the same thing. Worse, it doesn't get tired, so it'll keep cranking out commits all day while your human teammates are stuck in meetings.
Pretty soon you've got branches everywhere, and nobody knows which ones actually contain new work versus which ones are just AI reinventing the wheel. Your weekly standups turn into archaeological expeditions through Git history, and your junior developers start avoiding merge conflicts like they're personally cursed.
The good news? This isn't a fundamental AI problem - it's a workflow problem. And workflow problems have solutions.
Stop, Look, Then Leap: The "What Am I About to Blow Up?" Check¶
The biggest difference between working with AI on Git versus solo development? You need to become paranoid about checking what you're about to delete. Not because AI is malicious, but because it's fearless in ways that will make you sweat.
When Claude suggests deleting a branch, your first instinct should be "wait, what's actually on this thing?" Run git log --oneline main..HEAD to see every commit that lives only on your current branch. Then hit it with git diff origin/main..HEAD --name-only to see which files got touched. These two commands will save you from that sinking feeling of realizing you just nuked three days of work.
But don't stop there. Check git branch -r --merged main to see which remote branches are already safely merged into main. And git show-branch main feature-branch will show you the actual relationship between branches - sometimes what looks like a "clean" branch actually has commits that main doesn't know about.
Here's the thing: most developers skip these checks because they feel tedious. But recovering from accidentally deleting the wrong branch or corrupting a merge? That'll eat your entire afternoon and possibly your will to live. AI tools are actually perfect for running these investigation patterns every single time - they don't get impatient like humans do.
The "Is This Actually New?" Problem¶
Here's a mistake that'll make you question everything: you ask Claude to create a feature branch for some new functionality, and it cheerfully copies your entire existing app directory because "the user wants a feature branch for this application." Suddenly you've got a branch that looks incredibly productive but is actually just duplicating stuff that's already in main.
The fix is simple but requires discipline. Before you let AI create any feature branch, run git diff main..source-branch --name-status to see what's actually different. Files marked with "A" (added) are genuinely new and worth extracting. Files marked with "M" (modified) need a closer look - are these new features or just improvements to existing code?
Here's what good versus bad branch extraction looks like. A branch showing A apps/NewApp/ is legitimate - that's genuinely new functionality. But if you see M apps/ExistingApp/core.py mixed with A apps/ExistingApp/feature.py, you need to be more careful. The new feature file can be extracted, but those core modifications probably belong in a different branch focused on improving existing functionality.
The trick is remembering that AI thinks in terms of file systems and directories. You need to think in terms of business functionality. What capability are you actually adding? What's genuinely new versus what's just better? That distinction determines whether you're creating a clean feature branch or accidentally duplicating existing work.
Commit Messages That Don't Suck¶
AI-generated commit messages are like having a brilliant but socially awkward colleague write your documentation. They'll tell you exactly what changed ("Update user authentication logic") but completely miss why anyone should care or what it means for the system.
The problem is that six months from now, when something breaks and you're digging through Git history at 2 AM, "Update user authentication logic" tells you nothing. What was broken before? Why this approach? What happens if this code gets reverted?
Good commit messages need to answer the question your future self will be asking: "What was this person thinking?" Start with the business impact, then get into the technical details. For complex changes, explain why you chose this approach over alternatives - that context becomes gold when someone needs to modify or debug your code later.
For longer commit messages, use heredoc syntax to keep formatting clean:
git commit -m "$(cat <<'EOF'
Implement multi-factor authentication for admin accounts
- Add TOTP support using time-based tokens
- Integrate with existing LDAP authentication flow
- Require MFA for all admin-level operations
- Add backup codes for account recovery scenarios
Addresses security audit requirement for privileged access controls.
Tested with Google Authenticator and Authy mobile applications.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
This format does three things: it helps future developers understand why changes were made, provides implementation context for debugging, and maintains transparency about AI involvement while keeping humans accountable for the decisions.
The "Merge Early, Merge Often" Reality Check¶
Here's the uncomfortable truth: AI moves so fast that your traditional "wait until the feature is complete" branch strategy will kill you. While human developers can nurse a feature branch for weeks, AI-assisted branches start rotting after about 48 hours. The longer they live, the more likely they are to conflict with everything else happening on main.
This means you need to get comfortable with merging incomplete work. Merge as soon as a branch provides any incremental value, even if the whole feature isn't done yet. This feels wrong if you're used to "feature-complete" merging, but it's the only way to stay sane when AI is cranking out changes faster than your team can coordinate.
Think of it like this: branches are for isolation while you work, not for storage until you're done. Create from current main, focus on specific functionality, and merge within 24-48 hours max. If a branch lives longer than three days, it's usually a sign that you bit off more than you could chew - either merge what you have or break it into smaller pieces.
The exception is experimental branches where you're testing completely different architectural approaches. Those can live longer, but label them clearly and rebase regularly against main so they don't become impossible to integrate later.
Why This Actually Matters¶
Here's the thing about repository discipline: it's not just about keeping things tidy. It's about whether your team can actually ship software or gets bogged down in Git archaeology.
Bad Git practices turn every development day into a treasure hunt. You spend time figuring out which branch has the latest work, untangling merge conflicts that shouldn't exist, and trying to decode commit messages that tell you nothing useful. When you add AI to this chaos, it gets exponentially worse because AI can create problems faster than humans can clean them up.
But when you get Git discipline right, something interesting happens. Merge conflicts become rare because branches stay focused and short-lived. Your repository history becomes a useful resource instead of a confusing mess. Most importantly, developers spend their time building features instead of playing Git detective.
The benefits compound over time. New team members can actually understand what the codebase does by looking at the commit history. Code reviews focus on the actual work instead of trying to figure out what changed. Technical debt stays manageable because changes follow systematic patterns instead of random modifications scattered across dozens of branches.
The key insight is that good Git practices become even more valuable when AI joins your team, not less. The teams that establish this discipline early can leverage AI's speed without drowning in the chaos. The teams that skip it find themselves moving slower as their repository becomes impossible to navigate.
The Quick Start Checklist¶
Before any branch deletion or force push:
- Run git log --oneline main..HEAD to see what commits you'd lose
- Run git diff origin/main..HEAD --name-only to see affected files
- Check git branch -r --merged main for safe-to-delete branches
Branch extraction discipline:
- Always run git diff main..source-branch --name-status first
- Files marked "A" (added) are legitimate new functionality
- Files marked "M" (modified) need careful analysis
Commit message template: Use heredoc format for complex changes, include business context and technical details, and always add the AI co-authorship attribution.
Branch lifecycle: - Merge within 24-48 hours maximum - If a branch lives longer than 3 days, merge what you have or break it up - Keep experimental branches clearly labeled and regularly rebased
That's it. The rest is just building these habits until they feel automatic.