GitHub 发布了 2026 年 Octoverse 报告，统计过去一年开发者共向 GitHub 推送代码 179 亿次，超过 2024 和 2025 两年总和；总提交 343 亿次，合并的拉取请求 13 亿个。报告发现，带 Agent 配置的新仓库平均提交次数是不带配置仓库的 8 倍，9 月已有超过 40% 的拉取请求由 Agent 发起（3 月为 17%）。61% 的 Copilot 用户会同时使用多个模型，医疗、农业、采矿、建筑等领域的公开仓库也在快速增长。报告还显示 GitHub 开发者已超 2.25 亿，过去一年活跃开发者平均已在 GitHub 上 36 个月，现在平均每人跨仓库数比一年前多 10%。对读者来说，这份报告描述的是开发者正把 Agent 从试用变成日常协作对象，但具体效果仍取决于各自项目实践。
文中可用工具
- GitHub CopilotGitHub 的 AI 编程助手，报告显示多数用户会选用多个模型
- GitHub Actions自动化任务运行服务，报告称今年每秒运行 1440 次任务
- Dependabot自动更新依赖并减少已知漏洞的 GitHub 工具
- GitHub Pages托管静态网站的服务，文中用于发布洪水公告和灾害警报
- Gati基于 GitHub Pages 和 Actions 运行的尼泊尔灾害警报接力项目
- mathlib社区维护的计算机可验证数学库
展开详情收起详情：Octoverse 报告：2026 年提交与推送创新高，开发者用 Agent 构建⌄
原文发布：2026-10-29 00:07 · 首次收录：2026-10-29
GitHub 在年度大会 Universe 上宣布，要把 GitHub 打造成覆盖软件开发全流程的端到端平台。过去开发者主要写代码，现在则越来越多地让 AI 助手和 Agent 承担实现与验证工作，问题在于多模型、多工具、多仓库之间切换繁琐，代码变多后审查压力也增大。这次 GitHub 推出面向 Agent 的 Copilot 应用、能自动挑选和执行模型的 Copilot Fusion、可跨多个仓库并行运行的 Copilot projects，以及能在手机、VS Code、命令行和网页间接续的会话同步，还有能根据运行结果自我改进的自动化流程。此外，企业客户无需再单独购买 Copilot 订阅，按使用的 AI 额度付费即可。对普通开发者来说，这意味着可以把更多执行环节交给 Agent，自己专注于方向和决策。
文中可用工具
- GitHub Copilot app面向 Agent 的软件交付应用，从问题到合并都在一个界面里完成
- Copilot Fusion根据任务需要自动选择一个或多个模型来执行
- Copilot projects给 Copilot 一个目标，让它在多个仓库中并行运行 Agent 任务
- Session continuity在不同设备与工具间延续同一个云端 Agent 会话
- Copilot automations在仓库内创建 AI 工作流，可手动、定时或由事件触发，并能从结果中学习改进
- Copilot code review自动审查代码变更，发现值得关注的缺陷
- Copilot code review Max更深入的高严重度问题代码审查模式
- CloudflareGitHub 表示可继续使用的第三方工具之一，原文未说明具体用途
- DatadogGitHub 表示可继续使用的第三方工具之一，原文未说明具体用途
- FigmaGitHub 表示可继续使用的第三方工具之一，原文未说明具体用途
展开详情收起详情：GitHub Universe 2026：演进技术栈的每一层⌄
原文发布：2026-10-29 00:09 · 首次收录：2026-10-29
GitHub 漏洞赏金团队在网络安全意识月采访了研究员 @r31n。他专门研究 GitHub Enterprise Server，多次发现高危问题，报告里都附带可用的概念验证和清晰的复现步骤，让工程团队能更快定位并修复。他说自己偏爱把几个看似无害的小问题串成完整攻击链，比如一个开放重定向配上会跟随跳转的 SSRF。日常学习靠安全博客、漏洞分析和会议演讲，但真正掌握要靠亲手复现。他认为 AI 降低了入门门槛，也确实是效率放大器，但决定研究质量的是验证和真实影响，而不是工具。
展开详情收起详情：漏洞赏金如何磨砺一位研究员的安全技能⌄
原文发布：2026-10-23 01:21 · 首次收录：2026-10-23
GitHub 把 99.99999% 的仓库复制到了 Azure，但最繁忙的那一小部分仓库因为跨区域往返一次约 25 毫秒而搬不过去。原来的写入会锁住整个仓库，一次只能处理一个写入，最慢的副本拖慢了所有写入。现在 GitHub 把锁的范围从整个仓库缩小到单个引用（如分支），不同分支的写入可以同时进行，内部测试中写入吞吐提升了 3 到 4 倍。接下来，等数据都存进 Azure Blob Storage，读取就能和写入分开扩容，读者日常拉取代码时有望更快、高峰期也不容易被写入挤占。这一改动是已公布的架构演进，具体全面上线时间文中未说明。
展开详情收起详情：通往智能体规模 Git 基础设施的桥梁⌄
原文发布：2026-10-22 00:00 · 首次收录：2026-10-22
GitHub 博客采访了三位有十多年 Java 经验的 Java Champion，分享他们在真实项目和开源工作中使用 GitHub Copilot 的经历。共同点是：AI 能大幅加快写代码和做原型的速度，但开发者仍要提供上下文、审查生成的计划和代码，并对最终交付负责。例如 Vlad Mihalcea 原本预计要花几周开发的功能，借助 Copilot 两天就完成了；他还用自己 65 篇文章训练出模仿个人文风的技能，让生成的文档更像自己写的。Patrick Baumgartner 则用 Copilot 完成了约 900 张教学幻灯片从 Reveal.js 到 Marp 的迁移，并靠截图对比等方式逐项验证结果。这些经验目前属于个人实践分享，文章没有说明具体产品版本或开放范围。
文中可用工具
- GitHub Copilot在 IDE 中辅助写代码、做原型、迁移内容和生成文档
- IntelliJ IDEAVlad 运行 GitHub Copilot 的 IDE 环境
- Reveal.js原有教学幻灯片框架
- Marp迁移后的幻灯片框架
- Spring Boot原文提到用于架构与模块化的技术，未说明与 Copilot 的具体配合方式
- Spring Modulith原文提到用于模块化架构，未说明具体用途细节
- Spring Security原文提到用于安全相关实践，未说明具体用途细节
展开详情收起详情：3 位 Java Champion 如何用 GitHub Copilot 提升生产力⌄
原文发布：2026-10-21 00:05 · 首次收录：2026-10-21
GitHub 官方博客介绍了把 GitHub Copilot 应用里的智能体会话直接搬到 VS Code 继续做的方法。原来 Copilot 帮你改完代码后，想在编辑器里逐行检查、手动微调和本地运行，要么留在应用里，要么在 VS Code 里从头再来。现在只要点「Open in VS Code」，VS Code 会用同一个工作树打开项目，侧边栏保留原会话的任务、计划和对话记录，改动也直接呈现为可审阅的 diff。之后你可以自己改代码、跑测试、再让 Copilot 接着改，最后提交并推送到该会话对应的 pull request，全程不用重新描述任务。使用前需安装并登录 Copilot 应用和 VS Code、使用同一 GitHub 账号，并对目标仓库有推送权限。该功能当前已可用。
文中可用工具
- GitHub Copilot 应用运行智能体会话、完成代码修改的地方
- Visual Studio Code接收会话、审阅 diff、手动编辑并在本地运行测试的编辑器
展开详情收起详情：如何在 VS Code 中继续 GitHub Copilot 应用会话⌄
原文发布：2026-10-20 02:47 · 首次收录：2026-10-20
GitHub 员工在共享组织里和外部客户、合作伙伴一起做项目，时间一长，谁还需要访问权限、哪些仓库已经没人用了，靠人工记录很难跟上。他们做了一个叫 Evergreen 的 GitHub App，用 GitHub 自带的定时任务、webhook 和 issue 来干活：每季度给每个仓库开一张清单 issue 让人勾选保留谁，没人回复就默认收回权限；长期没人动的仓库会先警告、再归档，而且从不删除内容。所有状态存成 git 里的 JSON 文件，改动记录本身就是审计日志。这样仓库管理员不用再维护表格，也能保证权限不会一直留着。
文中可用工具
- Evergreen自动审查外部协作者访问权限并归档长期无活动仓库的 GitHub App
- GitHub Actions按季度定时触发工作流，作为 Evergreen 的时钟
- repository_dispatchGitHub 事件类型，用于唤醒 Evergreen 执行任务
- workflow_dispatch支持手动触发工作流步骤
- GitHub webhooks监听 issues.closed 等事件并驱动后续操作
- GitHub custom properties设置 evergreen_repo_owner 来指定仓库负责人
- Copilot可通过复制粘贴快速回滚误操作
展开详情收起详情：保持常青：我们如何在共享组织中自动化安全访问与仓库卫生⌄
原文发布：2026-10-16 02:00 · 首次收录：2026-10-16
GitHub 在博客中提出，软件开发正从"输入命令操作工具"转向"表达意图"。AI 能让系统理解代码仓库、挑选合适模型、规划任务、改文件、跑测试并检查失败，开发者只需描述想要的结果，GitHub Copilot 就能完成这些步骤，最后仍需人来判断结果是否可靠。文中还提到与罗技合作的 MX Keypad 实体按键，可把常用提示词或启动会话等操作映射到按键上，减少打断、保持专注。目前这仍处于早期探索阶段，作者也列出上下文保留多少、凭据如何限定、多个 Agent 如何协调等尚待解决的问题。读者可把它看作一次具体尝试：挑一个反复出现的打断，映射到一个按键，看是否真能帮助自己保持专注。
展开详情收起详情：下一代开发者界面：环境智能⌄
原文发布：2026-10-16 03:39 · 首次收录：2026-10-16
GitHub 过去要查看一个仓库的星标增长曲线，工具必须一页页拉取「谁点了星」的名单，每次最多 100 人，像 react/react 这样有约 25.1 万星的仓库要发约 2511 次请求。名单里带着用户名，容易被批量抓去发垃圾邮件和钓鱼，而且数据库每次请求还要数一遍全部星标来算页数，导致很多查询变慢甚至超时。现在 GitHub 新增了一个接口，一次请求就能返回最多 30 周的每日星标数，不带任何用户身份，做法是先在时间上过滤再统计，而不是先查全部再筛。对维护者来说，比较发布前后热度变化会快很多，也少了对隐私和数据库的负担。
文中可用工具
- Star History用来查看仓库星标随时间变化曲线的工具
- GitHub APIGitHub 提供的接口，用于读取仓库数据
展开详情收起详情：从 2500 次请求到 24 次：不返回 stargazers 也能重建星标历史⌄
原文发布：2026-10-15 03:11 · 首次收录：2026-10-15
GitHub 发布了 2026 年 9 月的可用性报告，回顾过去两个月为提升稳定性所做的工作。此前 GitHub 服务出现过宕机、性能下降等问题，原因是共享数据库压力过大、连接被耗尽、重试机制加剧拥堵。这次 GitHub 采取了一系列措施：迁移部分数据库和工作负载到 Azure、清理冗余数据、减少死锁、增加自动扩容和过载保护。对用户来说，部分改动已经上线，比如当共享依赖出故障时，约一半的 pull request 流量仍能有限度地继续使用；但迁移目标未按期完成，相关工作仍在进行中。
展开详情收起详情：GitHub 可用性报告：2026 年 9 月⌄
原文发布：2026-10-15 04:01 · 首次收录：2026-10-15
GitHub 改进了它用来扫描代码里密钥、密码等敏感信息的检测方式。以前用大型语言模型来判断，误报多、速度慢、成本高，因为很多看起来像密钥的字符串其实是测试用占位符或校验码。现在 GitHub 换成两段式流程：先用规则快速找出所有可疑字符串，再用一个专门训练的小模型 ModernBERT 结合文件路径、变量名和周围代码判断它是不是真的密钥。结果是用户接受警报的比例提高了 11.5%，扫描中位耗时降低 86%，服务器成本降低 98% 以上，并且这套方法已经用在提交前的拦截保护里。
文中可用工具
- ModernBERT一个经过微调的小型分类模型，负责判断可疑字符串结合上下文后是不是真正的密钥
展开详情收起详情：GitHub 的秘密检测模型：用更少的噪音发现更多秘密⌄
原文发布：2026-10-14 01:56 · 首次收录：2026-10-14
GitHub 官方博客介绍了让 Copilot 更懂你项目的四种自定义方式。原来每次让 Copilot 改代码，都得反复解释项目的命名规范、测试脚本和目录结构，新来的 Copilot 完全不了解这些“家规”。现在可以把这些知识直接写进仓库：用自定义指令说明通用规范，用 Agent 技能打包重复流程（如跑测试和 lint），用自定义 Agent 处理无障碍审查这类跨文件任务，还能通过 MCP 服务器接入 Playwright 等外部工具让 Copilot 在浏览器里实际操作验证界面。这样 Copilot 就能自动读取项目规则，减少重复说明，按团队既定流程干活。文章还推荐了社区分享的 Awesome Copilot 资源库，并建议先从一个常被重复解释的规范开始，写进 .github/copilot-instructions.md 试起。
文中可用工具
- GitHub CopilotAI 编程助手，可根据项目上下文帮开发者改代码
- Playwright通过 MCP 服务器让 Copilot 打开浏览器并手动测试应用界面
- MCP servers把 Copilot 连接到外部工具、数据源和服务，扩展其能力
- Awesome Copilot社区分享的现成自定义指令、技能和 Agent 等资源集合
展开详情收起详情：GitHub Copilot 入门指南：如何让 Copilot 了解你的代码库⌄
原文发布：2026-10-13 01:43 · 首次收录：2026-10-13
很多过去觉得做软件门槛很高的人，现在也能动手做东西了。原因是用自然语言（比如直接说“帮我做个前端”）就能指挥 AI 帮自己写出代码，不再必须学很多年编程。GitHub 博客这篇采访了多场黑客马拉松的参与者，发现有人靠 GitHub Copilot 在半小时内做出前端并接上新闻 API，当有人遇到 bug 或演示失败时，也能当场重来。对读者来说，如果你有想法但不会写代码，可以先参加一场黑客马拉松，在两天里专注做出一个小原型，失败也没关系。文中的 GitHub Copilot 在博客里是既有产品或入口，但文中没有说明其独立应用何时开放；可用的具体工具和链接以原文为准。
文中可用工具
- GitHub CopilotAI 编程助手，能根据自然语言帮用户生成前端代码，并接入 API
- GitHub Student Developer Pack面向学生的开发者工具包，可免费使用 GitHub Copilot 等工具
展开详情收起详情：黑客马拉松为何仍是学习编程的最佳场所：与 GitHub Copilot 一起构建⌄
原文发布：2026-10-10 00:00 · 首次收录：2026-10-10
GitHub 的漏洞赏金团队为了庆祝网络安全意识月，专门介绍了他们赏金计划里的一位顶尖安全研究员 @vaib25vicky。他平时的工作，就是像普通用户一样去使用 GitHub 的各种功能，然后琢磨这些功能哪里可能被坏人利用。他特别擅长找和“权限控制”有关的漏洞，这次分享了他挑目标功能、验证漏洞的方法，也提到会用 AI 当助手，但强调 AI 给出的结果必须自己亲自验证过才能提交。对读者来说，这让人了解白帽黑客是怎么帮平台提前发现并修好漏洞、让大家的代码更安全的，也顺便知道了 GitHub 调整赏金规则、设了只邀请顶尖研究员的 VIP 计划，最高奖金能到三万美元甚至更多。
文中可用工具
- GitHub CopilotAI 编程助手，文章提到它正在改变软件开发方式，可能带来新的安全测试面
- Copilot coding agentAI 编程代理，同样被视为新的潜在攻击面
- HackerOne漏洞报告平台，文章建议通过它向 GitHub 提交安全发现
展开详情收起详情：一位漏洞赏金研究员如何挑选要调查的功能⌄
原文发布：2026-10-09 01:02 · 首次收录：2026-10-09
GitHub 发布数据称，如今每三个 pull request 中就有一个涉及 AI 智能体，而一年前不到十分之一；代码产出在加速，但泄露的密钥平均要等约 40 天才被人工撤销，五分之一甚至超过 90 天。为解决这个“开发快、修复慢”的失衡，GitHub 与 Microsoft Applied Sciences 合作训练了一个分类器，能在不到两毫秒内判断一组候选密钥，把推送保护扩展到没有固定格式的密钥，有望让可拦截的密钥数量翻倍以上。对开发者来说，更多密钥会在进入仓库历史前被自动拦下，少一些事后手动补救的麻烦。目前该模型的具体上线时间和可用范围，原文尚未说明。
展开详情收起详情：密钥保护必须跟上软件增长的步伐⌄
原文发布：2026-10-08 01:45 · 首次收录：2026-10-08
GitHub 正在一边保持线上服务运行，一边重建它的 Git 底层存储系统。过去每个仓库都在多台文件服务器上保存完整副本，加副本能加快读取，但每次写入也要同步所有副本，于是读扩展越多、写就越慢，难以承受成千上万个 AI 智能体并发提交。新架构的目标是把“数据持久保存”和“读取扩容”拆开，让写入不再被最慢的副本拖累。对普通开发者的直接好处是更快的推送、克隆和 CI，尤其是每天产生海量提交的仓库；目前这还只是重建工作的介绍，没有说明具体上线时间、迁移步骤和性能数据。
展开详情收起详情：为智能体规模开发构建 Git 基础设施⌄
原文发布：2026-10-07 04:57 · 首次收录：2026-10-07
GitHub 推出了 ReviewBench，一个用来评估 AI 代码审查工具的公开基准。此前，各家 AI 审查工具好坏难分：有的发现问题多但噪音大，有的漏报多，团队缺少统一标准来判断谁更适合自己。ReviewBench 参考了 GitHub 上超过 1 亿个真实 PR 的语言和规模分布，挑选了 19 种语言的 219 个公开 PR，用人工审查、前沿大模型和静态分析共同构建“标准答案”，并按严重程度和类别打分，衡量准确率和召回率。它还经过资深工程师独立校验，与线上实验方向基本一致，因此开发团队可以用它离线预判改动是否真的能改善用户体验。该基准目前已可直接使用，且开放提交结果。
文中可用工具
- ReviewBench一个公开基准，用于在统一标准下测试和比较 AI 代码审查工具
- Copilot code reviewGitHub 的 AI 代码审查功能，文中用 ReviewBench 对其进行离线评估
展开详情收起详情：ReviewBench：面向 AI 代码审查的开放基准⌄
原文发布：2026-10-05 23:59 · 首次收录：2026-10-06
GitHub 博客发表了一篇文章，讲的是 AI 正在改变开发者的干活方式，光会写代码已经不够了。文章建议开发者重点练三件事：一是学会“指挥”AI 智能体，把问题说清楚、给对上下文，而不是自己一行行写；二是不轻信 AI 的第一版答案，可以让另一个 AI 模型来挑毛病，再自己拍板；三是把省下的时间用来想更大的问题，比如判断用户需求、权衡架构方案、定义成功标准。对读者来说，这说明以后的核心竞争力可能不是你写代码有多快，而是你能不能判断 AI 写得好不好、该不该上线。文章只给了方向性建议，没有给出具体数据或发布日期。
文中可用工具
- GitHub CopilotAI 编程助手，文中提到它内置了 Rubber Duck agent。
- Rubber Duck agentGitHub Copilot 内置的评审智能体，用一个模型去审查另一个模型生成的计划、代码和测试。
展开详情收起详情：AI 正在改变开发者的工作方式，这里有三个需要加强的技能⌄
原文发布：2026-10-02 23:00 · 首次收录：2026-10-03