NetAlertX 仓库 Git 工作流指南：单分支直推、共享检出树与 AI 协作安全规则

后端网络运维数据可视化【免费下载链接】NetAlertXCentralized network visibility and continuous asset discovery. Monitor devices, detect change, and stay aware across distributed networks.项目地址https://gitcode.com/gh_mirrors/ne/NetAlertX点击查看免费下载本文基于仓库内的.gemini/skills/git-workflow/SKILL.md及与其配对的.github/skills/git-workflow/SKILL.md整理而成。NetAlertX 是一个面向家庭实验室、MSP 与 NOC 场景的网络资产发现与可视化平台其开发协作采用直接提交并推送到next_release的单分支模型而非常见的 feature-branch/PR 流程。阅读本文后你将掌握在该仓库中安全操作 Git 的三条核心守则未经确认不建分支、默认直推next_release、每次 push 前显式确认以及在任何改变共享状态的 Git 命令之前如何通过git status与git branch --show-current自检现场。为什么这份工作流规则存在共享检出树的现实风险NetAlertX 的仓库工作树并不一定是一个孤立的检出副本。维护者或协作者可能在同一仓库上同时开着多个终端会话——例如在 NAS/服务器 shell 与当前会话的工作目录并排操作。在这种共享检出场景下切换分支会改变共享的仓库状态从一个终端执行git checkout -b会静默改变从其他所有操作同一仓库的终端看到的git push/git status行为。该 skill 文档记录了真实发生过的困惑性故障用户自己的终端执行git push时因 no upstream branch 而失败原因是 AI 助手在未说明的情况下切换了分支。因此这份 skill 的第一条硬性规则是不要未经用户明确许可就创建分支。即使任务听起来暗示了分支与 PR 流程例如 prep a PR也必须先询问而不是擅自假设该仓库采用这种工作流。默认工作流直接提交并推送到next_release在未收到其他指示的情况下所有工作直接落在next_release分支上在该分支上执行git commitgit push的目标是origin next_release除非用户明确要求不要自行发明 feature-branch / PR 工作流从仓库现状看当前检出分支为main本仓库镜像分支而开发主线的next_release是文档明确指定的推送目标。这一约定与仓库的 CI 结构相呼应.github/workflows/code-checks.yml中大量质量检查Python 语法、flake8 lint、shellcheck、Docker 测试等都围绕main分支的 push 与 PR 事件触发而next_release承担开发流水的落点职能。每次 push 前必须显式确认无论目标是不是默认的next_release在运行git push之前都必须先获得用户的明确确认不要把 push 静默折叠进一个更大的任务里应当把 push 作为一个独立的步骤提出并等待用户的许可。这条规则的核心动机与第一条相同push 同样是改变共享仓库状态的操作。在多终端共享检出树的环境下一次未声明的 push 可能覆盖或干扰其他会话的进度。改变共享状态前的必做自检在运行任何会改变共享状态的 Git 命令之前先执行以下两条命令git status git branch --show-current自检的目的不要假设你上次离开仓库时的分支仍然处于检出状态——另一个进程或终端可能已经切换了它先确认当前分支与工作树状态再决定git checkout -b、git branch、git push等操作是否安全。从源码结构看这条自检要求与仓库对技能skill的镜像管理机制是一体两面的.gemini/skills/skills-index/SKILL.md明确说明同一份流程知识会以内容相同的方式同时维护在.gemini/skills/Gemini CLI与.github/skills/GitHub Copilot两个目录下并强调 keep body content identical——两份git-workflow/SKILL.md的正文确实逐字一致仅 frontmatter 的name/description按各自工具的发现机制略有差异。因此无论使用哪个 AI 助手读到的工作流规则都是同一份。仓库级佐证skill 配对与 CI 守护机制这份 Git 工作流 skill 并非孤立的备忘而是 NetAlertX 仓库AI 协作基础设施的一部分可以从以下仓库文件得到印证配对文件.github/skills/git-workflow/SKILL.md与关联文档内容完全一致供 GitHub Copilot 使用索引映射.gemini/skills/skills-index/SKILL.md提供了三个 AI 助手Gemini CLI、GitHub Copilot、Claude Code技能树的跨引用总表CI 漂移检查scripts/check_skill_pairs.py会对比一组镜像文件如.gemini/skills/git-workflow/SKILL.md与.github/skills/git-workflow/SKILL.md当某个 PR 只改了组内部分文件时输出告警——该检查在.github/workflows/code-checks.yml中以check-skill-pairs任务运行对 PR 事件触发continue-on-error: true非阻断式因为部分组存在有意的内容深度差异。这也意味着如果你需要更新这份 Git 工作流规则应同时修改.gemini/skills/git-workflow/SKILL.md与.github/skills/git-workflow/SKILL.md两侧以保持两个 AI 系统获取到一致的行为约定避免被 CI 标记为 skill-group drift。实践速查表场景正确做法禁止做法任务暗示需要新分支/PR先询问用户是否确实需要分支git checkout -b new-branch/git branch new-branch默认提交落点在next_release上 commit自行发明 feature-branch 流程推送代码单独提出 push 步骤并等待明确确认把 push 静默折叠进大任务执行任何改变共享状态的命令前先跑git statusgit branch --show-current假设上次的分支仍被检出结语NetAlertX 的 Git 工作流规则本质上是为多终端共享检出树 AI 辅助开发场景设计的协作护栏不建分支、直推next_release、push 前确认、操作前自检。遵守这些约定既能避免 no upstream branch 一类的真实故障也能让 AI 助手与人类维护者在同一份仓库上安全共存。如需深入了解该仓库的技能体系全貌可继续阅读.gemini/skills/skills-index/SKILL.md与仓库根目录的 CLAUDE.md。赞分享后端网络运维数据可视化【免费下载链接】NetAlertXCentralized network visibility and continuous asset discovery. Monitor devices, detect change, and stay aware across distributed networks.项目地址https://gitcode.com/gh_mirrors/ne/NetAlertX点击查看免费下载相关推荐NetAlertX 仓库 Git 工作流规范AI 助手在共享仓库中的分支、提交与推送协作指南NetAlertX 仓库 Git 工作流规范AI 助手在共享仓库中的分支、提交与推送协作指南 本指南依据仓库内 .claude/skills/git work后端网络运维数据可视化ESPectre 仓库工程协作规范全解Agent 规则、分层边界与验证工作流ESPectre 仓库工程协作规范全解Agent 规则、分层边界与验证工作流 ESPectre 是一个面向 ESP32 的 Wi Fi CSI 运动感测项目人工智能机器学习物联网嵌入式智能硬件边缘计算Git协作安全终极指南如何正确设置分支保护规则保护你的代码仓库 Git协作安全终极指南如何正确设置分支保护规则保护你的代码仓库 在团队协作开发中 Git分支保护规则 是确保代码质量和项目安全的关键防线。无论你是刚接教程文档上一篇OpCore-Simplify黑苹果配置的终极自动化实战指南下一篇WVP-GB28181-Pro企业级视频监控平台实战指南从部署到优化的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考