Skip to content
vincere_

Working with Git

Git is more than version control for us. It’s how we collaborate asynchronously, share knowledge, and maintain a high-quality codebase. With AI agents now part of our workflow, the way we use Git has evolved — but the principles remain the same.

Branching Model

We use trunk-based development (TBD). It aligns with our culture of rapid development and continuous delivery.

Why TBD

  • Smoother and quicker development cycles.
  • Reduces the risk of large, complex merge conflicts.
  • Smaller changes mean more frequent releases and faster delivery.
  • Ensures only essential, well-tested code reaches production.

What TBD Requires

  • CI/CD pipelines to support the rapid flow of changes.
  • Commitment to writing tests for every change.
  • Discipline to never break the build.

Git Workflow

Whether you’re writing code yourself or working with an AI agent, follow these rules:

  1. Always branch from primary branch, e.g main. Run git pull origin main before creating a new branch.
  2. Keep branches short-lived. Long-lived branches lead to merge conflict hell.
  3. Small commits, small PRs. Aim for max 10 files per PR.
  4. Write tests. Unit tests at minimum, integration or end-to-end when appropriate.
  5. Never break CI/CD. If the pipeline is red, fix it before anything else.
  6. Use feature flags for incomplete features. Don’t merge half-done work behind no guard.
  7. Rebase on your own branch, squash when merging to main.

Working with AI Agents

When an AI agent creates commits and PRs on your behalf:

  • You own the output. The agent is a tool — you are responsible for what gets merged.
  • Review every commit. Read the diff, don’t just skim the PR description. Check that the agent followed project conventions and didn’t introduce unnecessary changes.
  • Verify tests pass. Confirm the agent wrote meaningful tests, not just tests that pass. Check edge cases and error handling.
  • Check commit messages. Agent-generated commits should follow the same conventions as manual ones. Edit them if they don’t.
  • One PR, one task. This applies to agents too. If an agent bundles unrelated changes, split them.

Branch Naming

Use a consistent naming convention so it’s clear what each branch is for:

feature/short-description
fix/short-description
chore/short-description

Pull Request Culture

PRs are how we learn from each other. Every PR — whether authored by a human or an agent — goes through the same review process.

For The Author

  • Run formatters and linters before committing. Use Prettier for JS/TS files, project-specific linters for other languages.
  • Code should be DRY and readable. Write reusable functions, don’t copy-paste.
  • Small PRs are preferred. Large PRs often hide bugs.
  • Include a screenshot or video for UI changes.
  • Link the ticket number in the PR description.
  • One PR, one task. Unrelated changes go in a separate PR.
  • If the PR was created by an AI agent, mention it in the description and note what you reviewed or changed.

For The Reviewer

  • Review PRs in the morning or before lunch so the author can act on feedback during the day.
  • Be constructive. Provide actionable feedback, not criticism. Keep ego out of reviews.
  • Never merge if CI is broken.
  • For agent-generated PRs: Pay extra attention to edge cases, error handling, and whether the code truly fits the existing architecture. Agents can produce code that works but doesn’t match how the team would write it.