TL;DR: Git only pays off when you have the right automation and discipline in place. Learn the basic cycle, what’s a useful commit message, and let your AI handle the rest.
The simple version
Git is a version control system — the world’s most reliable undo button for text files. It sounds technical because developers got there first. Ignore that.
For a company, Git does three things:
- Tracks every change to your files
- Explains why the change happened through commit messages
- Lets your AI query the full history later
The basic cycle
- Edit files — Make changes to your Markdown docs, SOPs, contracts, or any text file.
- Stage changes — Tell Git which edited files you want to save in the repository.
- Commit — Save a snapshot with a message describing what changed and why.
- Push — Upload your commits so your team and your AI can see them.
- Pull — Download your teammates’ latest commits before you start working.
That’s it. Three commands (git add, git commit, git push) cover most of the job. If you need to actually write them, your AI can guide you through each one. But you shouldn’t ever have to.
Handling merge conflicts
Two people edited the same file and pushed? Git stops and flags a merge conflict.
Cloud sync creates duplicates: Proposal (John's conflicted copy).docx. Git shows both versions inline with markers. Let your AI do the merging, keeping the changes that matter on both sides.
Because your files are plain text, an AI can resolve conflicts in seconds without breaking anything.
Writing commit messages that humans and AI can read
A good commit message answers two questions:
- What changed?
- Why did it change?
Follow a consistent format:
<area>(<scope>): Short summary of what changed
Longer description explaining why — constraints, tradeoffs, context.Use business areas your team understands:
strategy— Company direction, positioning, major decisionssales— Pipeline, proposals, pricing, customer notesmarketing— Website, campaigns, social, positioningfinance— Forecasts, budgets, invoices, reportingops— SOPs, processes, vendors, internal workflowshr— Hiring, onboarding, reviews, policieslegal— Contracts, compliance, risk notesproduct— Roadmap, specs, feedback, releasessupport— Customer issues, help docs, recurring problemsadmin— Housekeeping, templates, folder structure
Examples:
marketing(website): Update pricing page for Q3
Increased Enterprise tier from $99/mo to $149/mo based on competitive analysis.
Added "Annual" option with 2-months-free discount.ops(sops): Add contractor onboarding checklist
Added the missing account setup and offboarding steps so contractors follow the same process as employees.The consistency turns your repository into a searchable decision log.
Real examples: querying your history
Your Q3 forecast shows different numbers than last week. With Google Drive, you dig through version history and guess.
With Git, you ask your AI:
Show me who changed the Q3 revenue forecast and the previous values.The AI will show you the exact diff, who made it, when, and why — using a command so appropriately named git blame.
Problem solved. No file archaeology. No version-history cave diving.
Changes related to a product? Instead of opening every file one by one, you ask your AI:
How did Product X evolve over the last 3 months?The AI runs git log --since="3 months ago" --grep="product x" --oneline and returns a timeline of every decision, why it was made, and who made it. Same result.
Let the AI do the pushing
The biggest objection to Git is discipline. Good news: your AI handles the cycle.
Manual: the /commit-session command. Set up a command in OpenCode or Hermes Agent. When you finish a work session, type /commit-session. The AI:
- Reviews your changes
- Pulls the latest changes before preparing commits
- Resolves conflicts if needed
- Stages the right files
- Creates one or more clean commits
- Pushes the result
No thinking. No context-switching. The AI knows what you did — it was there.
Automatic: scheduled sync. Same principle, but it runs as a scheduled job every 15-60 minutes. A separate AI conversation pulls pending changes, creates smaller well-crafted commits, resolves conflicts, and pushes.
Both approaches work together. The manual command gives you clean checkpoints after focused work. The scheduled job catches anything you forget — with intelligent commits, not a dumb auto-snapshot.
Set up the commit-session command
OpenCode and Hermes can both create the command for you. The flow is: pull latest changes, resolve conflicts, stage files, commit, push. Tell your AI:
Create a slash command called /commit-session with this instruction:
Pull. Review the current session's changes and create the appropriate Git commit or commits. Push.
Rules:
1. Pull the latest changes before preparing commits so the history stays clean.
2. Resolve any merge conflicts carefully using both sides' context.
3. Review staged, unstaged, and relevant untracked files.
4. Do not commit secrets or environment files.
5. Do not include unrelated changes unless they are clearly part of the same session work.
6. If the work naturally splits into multiple logical commits, create multiple commits.
7. Explain the proposed commit grouping before committing if the split is non-obvious.
8. If there are no changes to commit, say so instead of creating an empty commit.
9. Push after committing, unless the repository has no remote or pushing would be unsafe.
Commit message format:
<area>(<scope>): Short summary of what changed
Longer description explaining why — constraints, tradeoffs, context.
Use business areas your team understands:
- strategy: Company direction, positioning, major decisions
- sales: Pipeline, proposals, pricing, customer notes
- marketing: Website, campaigns, social, positioning
- finance: Forecasts, budgets, invoices, reporting
- ops: SOPs, processes, vendors, internal workflows
- hr: Hiring, onboarding, reviews, policies
- legal: Contracts, compliance, risk notes
- product: Roadmap, specs, feedback, releases
- support: Customer issues, help docs, recurring problems
- admin: Housekeeping, templates, folder structure
Subject line rules:
- Required
- Max 50 characters
- Start with an action verb
- Capitalize the first letter
- No trailing period
- Specific enough to understand in Git logs
Body rules:
- Optional for tiny changes, recommended for anything non-trivial
- Explain why and how, not just what
- Mention constraints, tradeoffs, edge cases, and challenges when useful
- Wrap lines at 72 characters
- Use bullets if they make the change easier to scan
Hard rules:
- Do not add a footer section
- Do not add Signed-off-by, Co-authored-by, or metadata footers
- Do not append unrelated metadata after the body
- When using shell commands, run git add and git commit in the same command line
Examples:
marketing(website): Update pricing page for Q3
Increased Enterprise tier from $99/mo to $149/mo based on competitive analysis.
Added "Annual" option with 2-months-free discount.
ops(sops): Add contractor onboarding checklist
Added the missing account setup and offboarding steps so contractors follow the same process as employees.
Focus on clean, accurate commit history that a human and an AI can understand later.Now /commit-session becomes a reusable command. One sentence in. Clean history out.
Schedule it
Hermes can manage scheduled jobs directly, and you can observe the results. You do not need to write cron syntax by hand. From the Hermes chat, say:
Create a cron job called "commit-session".
Run it every 30 minutes during working hours.
In the company repository, review the current changes, split them into clean logical commits when needed, never commit secrets, pull before preparing commits, resolve conflicts carefully, commit, then push.
If there are no meaningful changes, do nothing.
Send me a short summary after each run.Then check the job in Hermes in its UI or with:
Show me my scheduled jobs and confirm commit-session is active.That’s the boring part automated. Which is the point.
OpenCode doesn’t have a built-in scheduler, but you can achieve the same with your computer’s own scheduler — cron on Linux/macOS or Task Scheduler on Windows. Set it to run opencode /commit-session in the repository directory at your chosen interval. You’ll need to redirect logs to a file and check them periodically. Less convenient than Hermes, but the same result.
Going further
Branches let you work on multiple versions of a file simultaneously. Developers use them constantly. For company files — SOPs, forecasts, proposals — you don’t need them. A single main branch with clear commits is simpler and your AI can navigate it just fine.
Git LFS (Large File Storage) replaces large files with text pointers so your repo stays fast. You may not need it in the beginning. Without LFS, every version of a large file lives in Git’s history forever. It matters for:
- Design files — PSDs, AI files, Figma exports (if you version them)
- Audio/Video — recordings, training materials, demos
- Datasets — CSV/JSON exports over a few MB
- PDFs — contract templates, formal reports (if you version them)
- Not typically needed for — screenshots, most JPGs, code-generated assets
Install LFS once per machine:
git lfs installTrack a file type in your repo:
git lfs track "*.psd"
git add .gitattributes
git commit -m "admin(lfs): Track PSD files with Git LFS"After that, Git handles everything automatically. No extra steps for your team or your AI.
The takeaway
Git is not hard because the concepts are hard. It is hard because people forget the routine.
So don’t rely on memory. Teach the routine to your AI once. Then let it keep the history clean.
Your company gets the win: files you own, history you can query, and commits that explain the work instead of hiding it.
What’s next
Skills are built. Now put them to work: Markdown CRM for relationships, PDFs for documents, Decks for presentations, Social Posts for content.
Your data. Your rules. Let’s write it that way. By Charles Henri Gayot.