code996 是一个分析工具，它可以统计 Git 项目的 commit 时间分布，进而推导出项目的编码工作强度。
它可以帮助你了解新团队工作的时间模式，识别潜在的加班文化。
使用方法很简单，一行命令即可开始：npx code996
简体中文 | English
面试时我们会询问面试官加班情况，但得到的答案有时不那么真实。但是代码的提交时间不会骗人，因此就有了这个工具。
当你入职新公司，跑一下 npx code996，就可以看到数据背后的真相，从而判断这家公司的真实加班文化。
与其痛苦三个月，不如早点看清真相！别等到试用期结束才后悔！
- 📊 996 指数：将复杂的加班情况转化为直观数值，一眼看穿项目卷度
- 🕰️ 智能工时推演：采用分位数与拐点检测算法，精准还原团队真实的上下班时间窗口
- 📈 月度趋势追踪：通过趋势识别项目是“越来越卷”还是“趋于平稳”
- 📅 多维度加班画像：全方位分析，不仅识别工作日/周末加班高峰，还能识别团队成员的加班比例
- 📦 多仓库对比：支持一键扫描并分析文件夹下的多个仓库，自动生成对比
- 🌍 跨时区检测：自动识别时区分布，支持指定时区精准分析
- 🇨🇳 节假日调休支持：内置国内节假日调休逻辑，精准剔除调休干扰
- 🔒 隐私安全：纯本地运行，基于 git log 进行离线分析
首先确保你本地有 Node.js环境，然后：
# 在当前仓库或仓库上级目录运行
npx code996你也可以选择安装后再使用，这样就不用每次都重新下载：
# 全局安装
npm i -g code996
# 使用
code996code996 会根据上下文自动选择最合适的分析模式：
- 在Git仓库中运行 → 单仓库深度分析
- 目录下有多个仓库 → 自动进入多仓库分析模式
# 智能检测，自动选择分析模式
code996 # 智能检测当前环境
code996 /path/to/repo # 分析指定仓库
code996 /proj1 /proj2 # 自动进入多仓库模式
code996 /workspace # 自动扫描子目录| 选项 | 简写 | 描述 |
|---|---|---|
--year <year> |
-y |
指定年份或年份范围（推荐）。单年：2025；范围：2023-2025 |
--since <date> |
-s |
自定义开始日期 (YYYY-MM-DD) |
--until <date> |
-u |
自定义结束日期 (YYYY-MM-DD) |
--all-time |
- | 覆盖整个仓库历史数据 |
| 选项 | 简写 | 描述 |
|---|---|---|
--hours <range> |
-H |
手动指定标准工作时间（如 9-18）⭐ 推荐使用，可获得更准确的结果 |
--half-hour |
- | 以半小时粒度展示时间分布（默认按小时）📊 更精确 |
--timezone <offset> |
- | 指定时区进行分析（如 +0800、-0700）🌍 适用于跨时区团队 |
--cn |
- | 强制开启中国节假日调休模式（+0800 时区自动启用） |
--self |
- | 仅统计当前 Git 用户的提交记录 |
--ignore-author <regex> |
- | 排除匹配正则的作者（如 bot|jenkins） |
--ignore-msg <regex> |
- | 排除匹配正则的提交信息（如 ^Merge|lint） |
# ===== 单仓库分析（智能模式） =====
code996 # 分析当前仓库（最近一年）
code996 /path/to/repo # 分析指定仓库
code996 -y 2025 # 分析2025年
code996 -y 2023-2025 # 分析2023-2025年
code996 --all-time # 查询整个仓库历史
code996 --self # 只分析当前用户的提交
code996 --self -y 2025 # 分析自己在2025年的提交
# ===== 多仓库分析（智能自动检测） =====
code996 # 如果子目录有多个仓库，自动进入多仓库模式
code996 /path/proj1 /path/proj2 # 传入多个路径，自动分析多个仓库
code996 /workspace # 扫描指定目录的所有子仓库
code996 /workspace -y 2025 # 分析2025年的数据和趋势
code996 --self # 只统计当前用户在所有仓库中的提交
# 手动指定工时（推荐）
code996 --hours 9.5-18.5 # 指定 9:30-18:30（支持小数）
code996 --hours 9.5-19 -y 2025 # 结合年份分析
# 精细分析（半小时粒度）
code996 --half-hour # 以半小时粒度展示时间分布
code996 -y 2025 --half-hour # 结合年份分析，精细展示
code996 /proj1 /proj2 --half-hour # 多仓库分析，半小时粒度展示
# 跨时区项目分析
code996 --timezone="+0800" # 只分析东八区（中国）的提交
code996 --timezone="-0700" # 只分析西七区（美国西海岸）的提交
code996 -y 2025 --timezone="+0800" # 分析2025年特定时区的提交
# 中国节假日调休分析
code996 # 系统自动检测主要时区为 +0800 时，会自动启用节假日调休
code996 --cn # 手动强制开启节假日调休模式（适用于非 +0800 时区项目）
code996 --timezone="-0700" --cn # 分析非中国时区项目，但需要按中国节假日调休判断
# 过滤噪音数据（排除 CI/CD 机器人、合并提交等）
code996 --ignore-author "bot" # 排除所有包含 "bot" 的作者
code996 --ignore-author "bot|jenkins|github-actions" # 排除多个作者（使用 | 分隔）
code996 --ignore-msg "^Merge" # 排除所有以 "Merge" 开头的提交消息
code996 --ignore-msg "merge|lint|format" # 排除多个关键词
code996 -y 2025 --ignore-author "renovate|dependabot" --ignore-msg "^Merge" # 综合过滤常见排除场景：
# 排除所有 CI/CD 机器人
--ignore-author "bot|jenkins|github-actions|gitlab-ci|circleci|travis"
# 排除依赖更新机器人
--ignore-author "renovate|dependabot|greenkeeper"
# 排除合并和格式化提交
--ignore-msg "^Merge|^merge|lint|format|prettier"
# 排除自动生成的提交
--ignore-msg "^chore|^build|^ci|auto"- 使用 git-log 获取项目 commit 的相关数据
- 本地计算分析，并打印出展示结果
Git 仓库 → git log 采集 → 日级首提 + 小时分布 → 分位数推算上/下班 → 996 指数计算 → 结果输出
- 时间分布分析：
- 数据采集：按分钟级别采集提交时间，自动聚合为48个半小时点
- 算法处理：自动聚合为24小时用于工作时间识别和996指数计算
- 展示模式：默认按小时展示（24点），可选半小时模式（48点）
- 工作时间识别：使用最近样本的 10%-20% 分位估算上班时间区间，并结合晚间提交拐点推算下班时间
- 996 指数计算：依据加班比例构建指数，并输出中文描述
- 项目类型识别 ：通过工作时间规律性、周末活跃度、晚间活跃模式，自动识别项目是"公司项目"还是"开源项目"
- 跨时区协作检测：通过时区离散度和"睡眠时段"提交比例识别跨时区项目（阈值：非主导时区 >1%），并提供时区过滤建议
- 节假日调休识别：当主要时区为 +0800 且占比超过 50% 时，自动启用中国节假日调休判断（工作日/周末会考虑法定节假日和调休），其他时区可通过
--cn参数手动开启 - 数据验证：检验统计数据是否与总提交数一致，避免缺失导致的偏差
- 算法优势：新版本采用分位数与拐点估算，能更智能地排除深夜零星提交的干扰，精准定位真实的工作时间窗口
- 隐私保护：所有对 Git 数据的分析均在本地进行，不会上传任何结果或日志。
- 分析局限性：工具仅统计 git log 中的 commit 时间。然而，实际工作还包括开会、学习、维护文档、调试自测等活动。因此，报告无法覆盖全部的实际工作时间，分析结果准确性有限，请谨慎参考。
- 使用限制：本项目分析结果仅供个人参考，请勿用于 “作恶” 或不当用途。
- 免责声明：code996 不对使用、传播本程序及附属产物造成的任何后果承担任何责任。
以下是一些常见问题，如果你有其他问题，欢迎随时提出issue。
并非如此。code996 的核心价值在于打破信息差，用真实数据对抗口头画饼。
- 试用期即“验货期”：入职不代表卖身。法律规定的试用期也是我们对公司的考察期。如果第一天就发现是天坑，趁早止损也是一种避坑策略。
- 内推时背调：格局打开！你完全可以找在那家公司工作的内鬼朋友帮忙跑一下。这不就是最硬核的内推背调吗？🐶
- 决策依据：哪怕已经入职，有一份确凿的加班证据在手，无论是以此为由转岗，还是作为离职的决断依据，都比自我怀疑要强得多。
影响会有，但 code996 依赖的是统计学规律，只要 commit 样本达到一定数量，最终呈现的是团队整体的集体工作模式，特殊提交习惯在统计学上会被视为“噪声”被过滤掉。
虽然技术上可以实现，但最终刻意放弃了这个功能：
按用户查看 996 指数，这个功能太容易被异化和滥用了，它很容易被一些人拿去分析团队成员的“加班情况”。
虽然我前面已经不止一次强调了工具的局限性（实际工作还包括开会、学习、维护文档、调试自测等等），但你就是拦不住有些人只看数字🤦
这个项目的初衷是用来避坑项目的，而不是给内卷提供新的弹药。因此，项目只提供看团队和看自己（--self）两种视角。
最后，代码提交量和时间点不等于工作产出。如果将其用于绩效考核，不仅会导致团队为了刷数据而产生大量垃圾提交，更会破坏团队的信任。
接下来的功能都会沿着 WLB 和工作避坑的路线来开发，包括：更精细的加班比例分析、以及分析代码的屎山指数（复杂度分析），毕竟维护屎山也是导致 996 的罪魁祸首之一。
🤖 AI 协作伙伴注意：本项目采用标准化的 AI 协作流程，详情请查看 .docs/README.md 中的协作规范。
MIT License