核心用法
Git Log Tracker 是一个基于 Python 开发的 Git 提交索引工具，通过安装 post-commit hook 实现自动化数据采集。每次提交后，系统自动提取 commit hash、作者信息、分支、仓库路径、提交主题等元数据，写入本地 SQLite 数据库。用户可通过 git-log-tracker CLI 跨仓库查询提交历史，支持按 hash 前缀模糊搜索、多维度筛选（仓库、作者、日期、分支、标签）及统计报表生成。
工具提供三种工作模式：单仓库模式、多仓库扫描模式、全局自动模式。通过 scan 命令可批量发现目录内的 Git 仓库并选择性安装 hook；global 模式则配置 Git 模板目录，使新建仓库自动继承提交追踪能力。标签系统允许为仓库打分组标记（如 work/personal），实现跨项目的逻辑聚合查询。
显著优点
自动化与无侵入性：基于标准 Git hook 机制，无需修改现有工作流，安装后即可静默运行。数据采集在本地完成，无网络依赖，保障隐私安全。
跨仓库查询能力：传统 git log 局限于单仓库，该工具通过中心化索引打破边界，适合管理数十个微服务仓库或分散的个人项目。
轻量与可移植：纯 Python 实现，通过 uv tool install 单命令安装，数据以 SQLite/JSON/TOML 等开放格式存储，易于备份和迁移。
灵活的标签体系：仓库级标签（label）支持动态分组，同一仓库的多条历史记录可随标签变更即时重新归类，无需修改历史数据。
潜在缺点与局限性
环境依赖门槛：需预装 Python 3.8+ 及 uv 包管理器，Windows 用户可能面临路径处理差异。首次配置涉及交互式流程，对纯 CLI 用户不够友好。
数据孤岛风险：索引仅存储于本地 ~/.commit-logs/，无内置同步机制，多设备协作时需手动迁移数据库。若误删数据目录，历史索引不可恢复。
功能边界清晰：专注元数据索引，不存储代码变更内容（diff），无法替代 git blame 或代码审查工具。删除/更新操作仅影响索引，不修改实际 Git 历史。
性能天花板：SQLite 在十万级记录下表现良好，但超大规模仓库集群（如千人团队的单体仓库）可能遭遇查询延迟，无分布式架构支持。
适合的目标群体
- 多仓库维护者：同时维护个人项目、工作项目、开源贡献的技术人员，需要统一的提交历史视图。
- 自由开发者/数字游民：跨设备开发时希望快速定位"上周在某个项目修复的 bug"，却记不清具体仓库位置。
- 小型团队技术负责人：需要统计成员提交活跃度、识别长期未更新的遗留仓库。
- Git 重度用户：追求提交历史的数据化、可查询化，愿意用结构化数据替代
cd遍历 +git log的传统排查模式。
常规使用风险
数据持久性：reinstall 命令默认删除整个数据目录，误操作将导致标签映射和配置丢失。建议定期备份 ~/.commit-logs/ 目录。
Hook 失效场景：若手动修改 .git/hooks/post-commit 或仓库重新初始化，hook 可能被覆盖，导致后续提交漏记。status 命令可用于主动巡检。
路径敏感性问题：标签存储使用"归一化 repo_path"，跨操作系统（如 Windows 与 WSL 混用）可能因路径格式差异导致标签匹配失败。
版本兼容性：当前为 0.7.0 版本，数据库 schema 未来可能调整，升级前建议查阅 release note，避免旧版数据无法读取。