Gito

NayjestMIT活跃维护

用 LLM 做 GitHub 代码审查的 CLI 工具,只报高置信度的安全漏洞、Bug 和可维护性问题,减少噪音干扰。

An AI-powered GitHub code review tool that uses LLMs to detect high-confidence, high-impact issues—such as security vulnerabilities, bugs, and maintainability concerns.

v4.5.0发布于 2026-09-05 14:05 UTC465star45fork同步于 2026-11-07 07:32 UTC

怎么上手

由 README 提炼,执行前请确认
pip install gito.bot
gito setup
gito review
硬件要求按 README 说明

README 未说明显存或 GPU 型号要求;支持本地 LLM 服务(Ollama、vLLM、llama.cpp、SGLang、LM Studio 等)及 PyTorch/Transformers 内嵌推理,也可直接用云端 API。

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

开源 AI 代码审查工具,用任意 LLM 在 PR 或本地改动中找出高置信度的安全、缺陷与可维护性问题

用 LLM 做 GitHub 代码审查的 CLI 工具,只报高置信度的安全漏洞、Bug 和可维护性问题,减少噪音干扰。

核心能力

  • 并行调用 LLM 快速产出代码审查结果
  • 不绑定厂商,支持 OpenAI、Anthropic、Google 及本地模型
  • 代码直连所选推理服务,无中间服务器留存
  • 通过 GitHub Actions 自动审查 PR 并回帖评论
  • 可配置审查规则、严重级别与关注领域

容易踩的坑

需要 Python 3.11/3.12/3.13 和 Git,且需先运行 gito setup 配置 LLM API 类型与密钥(存于 ~/.gito/.env);GitHub Actions 方式需在仓库 secrets 中添加 LLM_API_KEY 并授予 pull-requests write 权限;本地 review 默认对比主分支且忽略未暂存文件,gito 命令可能需重启终端或改用 python -m gito。

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v4.5.0
  1. v4.5.0最新正式版2026-09-05 · 2026-09-05 14:05 UTC

    Minor release — two new ways to control which configuration Gito uses, plus a config-mistake warning and wider test coverage. No breaking changes; safe drop-in upgrade from any 4.4.x.

    #ChangeTypePR
    1--project-config — use a config file from outside the repositoryFeature#336
    2gito populate-project-config — generate a project config from the bundled defaultsFeature#314
    3Warning when a [prompt_vars] key shadows a real settingFix#334
    4Test coverage for core diff helpersInternal#149

    ✨ Features

    1. Share one configuration across many repositories

    The new global option --project-config (short: -c) points Gito at any configuration file, wherever it lives:

    gito --project-config ~/.gito/nestjs-review-config.toml review
    
    • Takes precedence over <repo>/.gito/config.toml, and applies to every command — review, ask, files, report, …
    • ~ is expanded, and a missing file fails fast with a clear error instead of silently falling back to the defaults.
    • Keep one config per stack (NestJS, TypeScript, Python…) instead of editing .gito/config.toml in every project.

    Side effect: space-separated values of global options are now routed correctly — gito -v 2 review previously ignored the subcommand and fell back to a bare review run.

    #336 by @Nayjest, closing #335 (reported by @aolin480).

    2. gito populate-project-config

    Creates <repo>/.gito/config.toml as a complete, editable copy of the bundled defaults — a starting point for customization:

    gito populate-project-config           # refuses to replace an existing config
    gito populate-project-config --force   # overwrite it
    

    [!NOTE] A full copy pins every setting to the current Gito version, so prompts and templates improved in later releases will no longer reach that project. If you only need a few tweaks, keep .gito/config.toml minimal and let the rest fall back to the defaults.

    #314 by @Frostand, addressing #312.

    🐛 Bug Fixes

    3. Misplaced settings in [prompt_vars] are no longer swallowed

    [prompt_vars] is an open dictionary with no schema of its own, so a top-level setting accidentally nested inside it was absorbed without a trace:

    [prompt_vars]
    post_process = "..."   # ← meant for the top level; silently had no effect
    

    Such keys are now reported in the log, naming the setting and telling you to move it out of the section. The check reads the ProjectConfig field names directly, so it stays correct as settings are added or renamed.

    #334 by @AmirF194, fixing #313.

    🧪 Tests & Internals

    4. Coverage for the core diff helpers

    New tests for filter_diff, is_binary_file, base-branch resolution and file reading, a make coverage target, and a clearer error message when filter_diff is given invalid filters.

    #149 by @Nayjest.

    📚 Documentation

    The Configuration Cookbook now covers both new workflows — generating a project config to start from, and sharing one config across projects — and the CLI Reference documents the new option and command.

    ⬆️ Upgrading

    pip install -U gito.bot~=4.5
    

    Workflow templates generated by gito deploy now pin ~=4.5. Existing

  2. v4.4.42026-08-25 · 2026-08-25 12:42 UTC
    查看更新说明

    Patch release — safe to upgrade from any 4.4.x.

    Bug Fixes

    • Fixed non-ASCII paths being misclassified as binary and omitted from reviews, including deleted files and default merge-base comparisons. #317, fixing #188. Thanks @AmirF194.

    New Contributors

    Full Changelog: https://github.com/Nayjest/Gito/compare/v4.4.3...v4.4.4

  3. v4.4.32026-08-12 · 2026-08-12 20:06 UTC
    查看更新说明

    Patch release — safe to upgrade from any 4.4.x. Dependency and security maintenance only; no behavior or API changes.

    CI & Security

    Closes all 23 open Dependabot alerts. Every fix lands through the dependency graph — no Gito source changes were required.

    Package4.4.24.4.3Alerts
    GitPython3.1.503.1.5913 — command injection, arbitrary file read/overwrite, env-var exfiltration, git-config injection
    cryptography49.0.050.0.01 — PKCS#7 Bleichenbacher oracle
    pyasn10.6.30.6.43 — BER/CER/DER decoder denial of service
    mcp1.28.01.29.01 — WebSocket transport missing Host/Origin validation

    GitPython is a direct dependency (now pinned ^3.1.58) and is the one that matters most here: Gito drives git on your behalf, so the command-injection and arbitrary-file-write classes were directly reachable. The rest are transitive, arriving via google-auth, pyjwt/authlib, and ai-microcore/anthropic.

    Also upgraded ai-microcore ~6.4.4 → ~6.7.0 (latest), the library that handles all LLM access. Verified with a live end-to-end review run. (#331)

    Bug Fixes

    • Windows installer reported the wrong version. installer.iss hardcoded its own version string, which had silently drifted — the 4.4.2 installer identified itself as 4.4.1 in Add/Remove Programs and in its filename. The version is now injected by CI from the package metadata, the same importlib.metadata source everything else reads, so it can no longer drift. (#331)
    • Installer binary had a blank FileVersion. VersionInfoVersion was never set, so the setup .exe properties dialog showed no version. Now stamped. (#332)

    Documentation

    • CONTRIBUTING.md restructured. (#330)
    • Clarified that fork AI-review workflows are Anthropic-configured, not Anthropic-only.
    • AGENTS.md: release notes documented as a mandatory release step, and the "version lives in one place" guidance corrected to cover the installer.

    Verification

    Tests pass on Python 3.11 / 3.12 / 3.13, flake8 clean, and the full Windows build chain was exercised before tagging: installer compiles at 4.4.3, ProductVersion/FileVersion/filename all agree, and the frozen gito.exe reports 4.4.3.

    Full changelog: https://github.com/Nayjest/Gito/compare/v4.4.2...v4.4.3

  4. v4.4.22026-08-11 · 2026-08-11 19:40 UTC
    查看更新说明

    Patch release with bug fixes and CI hardening. No new features or breaking changes — safe drop-in upgrade from any 4.4.x.

    🐛 Bug Fixes

    • Silent None responses from the LLM no longer produce empty reviews. When the model returns no answer, the review run now surfaces a clear error instead of silently generating an empty report (#320 by @zurheidegenetthx379-ui)
    • Fixed crashes on empty LLM answers in gito ask / answer(), and gito react-to-comment now replies gracefully when the diff context is empty and fails the run on an empty LLM answer instead of posting nothing (#318 by @Dev9269)
    • gito deploy --commit no longer fails when the deploy branch already exists — re-runs now reset the branch via checkout -B (#318 by @Dev9269)

    🔒 CI & Security

    • AI code review on fork PRs is now gated behind the external-pr environment, so repository secrets are never exposed to untrusted code (#324)
    • Added a regression test asserting that any workflow job using secrets on untrusted triggers declares a protection environment (#326)
    • Code Style workflow now runs on pull requests (#322)

    📚 Documentation

    • Contributing guide: tests must never call a live LLM (#328)
    • AGENTS.md now documents the release process and version-bump locations (#329)

    New Contributors

    • @zurheidegenetthx379-ui made their first contribution in #320
    • @Dev9269 made their first contribution in #318

    Full Changelog: https://github.com/Nayjest/Gito/compare/v4.4.1...v4.4.2

  5. v4.4.12026-08-02 · 2026-08-02 13:51 UTC
    查看更新说明

    What's Changed

    • fix: load configuration files starting with a UTF-8 BOM (#316, fixes #315) — .gito/config.toml written by PowerShell/Notepad on Windows no longer fails with TOMLDecodeError; JSON report load/save now uses explicit UTF-8

    Full Changelog: https://github.com/Nayjest/Gito/compare/v4.4.0...v4.4.1

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    Gito is an open-source AI code reviewer that works with any language model provider. It detects issues in GitHub pull requests or local codebase changes—instantly, reliably, and without vendor lock-in.

    Get consistent, thorough code reviews in seconds—no waiting for human availability.

    📋 Table of Contents

    ✨ Why Gito?

    • [⚡] Lightning Fast: Get detailed code reviews in seconds, not days—powered by parallelized LLM processing
    • [🔧] Vendor Agnostic: Works with any language model provider (OpenAI, Anthropic, Google, local models, etc.)
    • [🔒] Private & Secure: Your code goes directly to your chosen LLM inference provider or local model—no intermediary servers
    • [🌐] Universal: Supports all major programming languages and frameworks
    • [🔍] Comprehensive Analysis: Detect issues across security, performance, maintainability, best practices, and much more
    • [📈] Consistent Quality: Never tired, never biased—consistent review quality every time
    • [🚀] Easy Integration: Automatically reviews pull requests via CI/CD workflows (GitHub Actions, etc), posts results as PR comments, and reacts to maintainer comments
    • [🎛️] Infinitely Flexible: Adapt to any project's standards—configure review rules, severity levels, and focus areas, build custom workflows

    🎯 Perfect For

    • Solo developers who want expert-level code review without the wait
    • Teams looking to catch issues before human review
    • Open source projects maintaining high code quality at scale
    • CI/CD pipelines requiring automated quality gates

    ✨ See code review in action ✨

    🌐 Supported Platforms & Integrations

    🧩 Git Platforms

    PlatformStatus
    GitHub✅ Supported
    GitLab🧪 Supported (Beta)
    Bitbucket🛠️ Planned
    Local / CLI✅ Supported

    ℹ️ Gito ships ready-to-use CI/CD workflows for these platforms, with full support for triggering actions via PR comments, automatic review posting, and PR lifecycle integration.

    Not on this list? Gito works anywhere—via custom CI/CD pipelines or directly from the CLI.

    🤖 LLM Providers / Runtimes

    Provider / RuntimeStatus
    OpenAI-compatible APIs Mistral, xAI, Azure, Amazon Bedrock, OpenRouter, Fireworks, and many more✅ Supported
    Anthropic API✅ Supported
    Google API✅ Supported
    Local LLM ServicesOllama, vLLM, llama.cpp, SGLang, LM Studio, etc.✅ Supported
    Embedded Inference using PyTorch / Transformers or custom python inference function✅ Supported
    Working on top of CLI-based LLM Tools / Coding Agent CLIs Claude Code, Gemini CLI, etc.✅ Supported

    🗂️ Issue Trackers

    ToolStatusDocumentation
    Jira✅ SupportedAtlassian Jira Integration ↗
    Linear✅ SupportedLinear Integration ↗

    🚀 More platforms and integrations are coming — Gito is built to grow with your stack.

    🔒 Security & Privacy

    Gito keeps your source code private by design: it is designed as a stateless, client-side tool with a strict zero-retention policy.

    • No middleman: Source code is transmitted directly from your environment (CI/CD runner or local machine) to your explicitly configured LLM provider. If you use a local model, your code never leaves your network. We never see your code.
    • No data collection: Your code isn't stored, logged, or retained by Gito.
    • Fully auditable: 100% open source. Verify every line yourself.

    🚀 Quickstart

    1. Review Pull Requests via GitHub Actions

    Create a .github/workflows/gito-code-review.yml file with the following content:

    name: "Gito: AI Code Review"
    on:
      pull_request:
        types: [opened, synchronize, reopened]
      workflow_dispatch:
        inputs:
          pr_number:
            description: "Pull Request number"
            required: true
    jobs:
      review:
        runs-on: ubuntu-latest
        permissions: { contents: read, pull-requests: write } # 'write' for leaving the summary comment
        steps:
        - uses: actions/checkout@v7
          with: { fetch-depth: 0 }
        - name: Set up Python
          uses: actions/setup-python@v6
          with: { python-version: "3.13" }
        - name: Install AI Code Review tool
          run: pip install gito.bot~=4.5
        - name: Run AI code analysis
          env:
            LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
            LLM_API_TYPE: openai
            MODEL: "gpt-5.5"
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            PR_NUMBER_FROM_WORKFLOW_DISPATCH: ${{ github.event.inputs.pr_number }}
          run: |
            gito --verbose review
            gito github-comment --token ${{ secrets.GITHUB_TOKEN }}
        - uses: actions/upload-artifact@v7
          with:
            name: ai-code-review-results
            path: |
              code-review-report.md
              code-review-report.json
    

    ⚠️ Make sure to add LLM_API_KEY to your repository's GitHub secrets.

    💪 Done!
    PRs to your repository will now receive AI code reviews automatically. ✨
    See GitHub Setup Guide for more details.

    Alternatively, install Gito locally and run gito deploy from your repository root. The deployment wizard will guide you through setting up AI-powered code reviews and automatically generate or update the required workflow files. GitHub Actions and GitLab CI are both supported. For GitLab, see the GitLab Setup Guide, or refer to the GitLab workflow templates for manual configuration.

    2. Running Code Analysis Locally

    2.1 Install Gito locally

    Note: If you use uvx, you can skip this step.
    When using commands like uvx gito.bot setup, uvx gito.bot review, uvx will install everything required on demand.

    Option 1: Install gito.bot using pip.

    Prerequisites:

    Run the following command to install the latest stable release from PyPI:

    pip install gito.bot
    

    Troubleshooting:
    pip may also be available via CLI as pip3 depending on your Python installation.

    To install from repository source / specific branch:

    pip install git+https://github.com/Nayjest/Gito.git@<branch-or-tag>
    

    Option 2: Windows Standalone Installer

    Download the latest Windows installer from Releases.

    The installer includes:

    • Standalone executable (no Python required)
    • Automatic PATH configuration
    • Start Menu shortcuts
    • Easy uninstallation
    2.2 Configure LLM connection

    The following command will perform one-time setup using an interactive wizard. You will be prompted to enter LLM configuration details (API type, API key, etc). Configuration will be saved to ~/.gito/.env.

    gito setup
    

    Alternatively, if you have uvx installed, you can run the setup command via uvx:

    uvx gito.bot setup
    

    Troubleshooting:
    On some systems, gito command may not become available immediately after installation.
    Try restarting your terminal or running python -m gito instead.

    2.3 Perform your first AI code review locally

    Step 1: Navigate to your repository root directory.
    Step 2: Switch to the branch you want to review.
    Step 3: Run the following command:

    gito review
    

    Note: This will analyze the current branch against the repository main branch by default.
    Files that are not staged for commit will be ignored.
    See gito --help for more options.

    Reviewing remote repository

    gito remote [email protected]:owner/repo.git <FEATURE_BRANCH>..<MAIN_BRANCH>
    

    Use interactive help for details:

    gito remote --help
    

    🔧 Configuration

    Gito uses a two-layer configuration model:

    ScopeLocationPurpose
    Environment~/.gito/.env or OS environment variablesLLM provider, model, API keys, concurrency
    Project<repo>/.gito/config.tomlReview behavior, prompts, templates, integrations

    Note: Environment configuration defines external resources and credentials — it's machine-specific and never committed to version control. Project configuration defines review behavior and can be shared across your team.

    Environment Configuration

    Environment settings control LLM inference, API Keys and apply system-wide.

    Gito uses ai-microcore for vendor-agnostic LLM access. All settings are configured via OS environment variables or .env files.

    Default location: ~/.gito/.env
    (Created automatically via gito setup)

    Example
    # ~/.gito/.env
    LLM_API_TYPE=openai
    LLM_API_KEY=sk-...
    LLM_API_BASE=https://api.openai.com/v1/
    MODEL=gpt-5.5
    MAX_CONCURRENT_TASKS=20
    

    For all supported options, see the ai-microcore configuration guide.

    CI/CD Environments

    In CI workflows, configure LLM settings via workflow environment variables. Use your platform's secrets management (GitHub Secrets, GitLab CI Variables) for API keys.

    Project Configuration

    Gito supports per-repository customization through a .gito/config.toml file placed at the root of your project. This allows you to tailor code review behavior to your specific codebase, coding standards, and workflow requirements.

    Configuration Inheritance Model

    Project settings follow a layered override model:

    Bundled Defaults (config.toml) → Project Config (<your-repo>/.gito/config.toml)

    Any values defined in your project's .gito/config.toml are merged on top of the built-in defaults. You only need to specify the settings you want to change—everything else falls back to sensible defaults.

    To create a complete, editable copy of the bundled defaults in the current repository, run:

    gito populate-project-config
    

    The command creates .gito/config.toml and refuses to replace an existing project configuration (pass --force to overwrite it).

    Note that a full copy pins every setting to the current Gito version: prompts and templates improved in future releases will no longer reach your project. If you only need a few tweaks, keep the config minimal and let the rest fall back to the defaults.

    Common Customizations
    • Review prompts — Tailor AI instructions, review criteria, and quality thresholds
    • Output templates — Customize report format for GitHub comments and CLI
    • Post-processing — Python snippets to filter or transform detected issues
    • Bot behavior — Mention triggers, retries, comment handling
    • Pipeline integrations — Jira, Linear, etc.

    Explore the bundled config.toml for the complete list of available options.

    Example
    # .gito/config.toml
    mention_triggers = ["gito", "/check"]
    collapse_previous_code_review_comments = true
    
    # Files to provide as context
    aux_files = [
        'documentation/command_line_reference.md'
    ]
    
    exclude_files = [
        'poetry.lock',
    ]
    
    [prompt_vars]
    # Custom instructions injected into the system prompts
    awards = ""  # Disable awards
    requirements = """
    - All public functions must have docstrings.
    """
    

    For detailed guidance, see the 📖 Configuration Cookbook.

    📚 Guides & Reference

    For more detailed information, check out these articles:

    Or browse all documentation in the /documentation directory.

    🚧 Known Limitations

    Gito cannot modify files inside .github/workflows when reacting to GitHub PR comments (e.g., "Gito fix issue 2").
    This is a GitHub security restriction that prevents workflows from modifying other workflow files using the default GITHUB_TOKEN.

    While using a Personal Access Token (PAT) with the workflow scope would bypass this limitation, it is not recommended as a workaround. PATs have broader permissions, longer lifespans, and are tied to individual user accounts, making them less secure than the default GITHUB_TOKEN for CI/CD pipelines.

    💻 Development Setup

    Clone the repository and navigate to it:

    git clone https://github.com/Nayjest/Gito.git
    cd Gito
    

    Install dependencies:

    make install
    

    Note: If make is not available on your system, you can run the underlying command directly:
    pip install -e ".[dev]"
    See the Makefile for all available commands.

    Format code and check style:

    make black
    make cs
    

    Run tests:

    pytest
    

    🤝 Contributing

    Looking for a specific feature or having trouble?
    Contributions are welcome! ❤️
    See CONTRIBUTING.md for details.

    📝 License

    Licensed under the MIT License.

    © 2025–2026 Vitalii Stepanenko