git分支变动通知钉钉或企业微信，核心依赖webhook+机器人api，需在代码平台（gitee/gitlab/github）配置触发事件（如push、merge request），并在钉钉/企微侧配置对应机器人webhook地址及安全机制（如钉钉加签、企微secret），缺一不可。
直接结论：Git 分支变动通知到钉钉或企业微信群，核心靠 Webhook + 机器人 API，不是 Git 自带功能，必须在代码平台（Gitee/GitLab/GitHub）侧配置触发，在钉钉/企微侧配置接收入口——漏掉任一端，消息就发不出来。
Git 平台怎么配 Webhook 才能触发分支变动事件
Webhook 不是“监听分支”，而是监听 push、merge_request、tag_push 这类具体事件。分支变动（如 git push origin dev 或 PR 合并到 main）本质是这些事件的副产物。
- GitLab 配置路径：
项目设置 → Webhooks → 添加 webhook，URL 填钉钉/企微机器人的 Webhook 地址；勾选Push events（推送到任意分支都会触发），如果只关心合并行为，再勾选Merge Request events并在后续逻辑里判断object_attributes.action == "merge" - Gitee 同理：
仓库管理 → Webhooks → 新建 Webhook，关键要勾选代码推送（push）和Pull Request，否则仅改 README 不会触发 - GitHub 要注意：
Settings → Webhooks → Add webhook，Payload URL 填机器人地址，Which events would you like to trigger this webhook?必须选中Pushes和/或Pull requests；默认不勾选Branch or tag creation，新建分支不会通知——这点常被忽略 - 所有平台都建议开启
SSL verification（尤其生产环境），否则可能因证书校验失败导致请求静默丢弃
钉钉机器人和企业微信机器人配置差异点
两者都是 HTTP POST 接口，但签名机制、字段格式、限流策略完全不同，混用会 400 或 403。
- 钉钉必须开启“加签”才能用于生产环境，否则任意 HTTP 请求都能伪造消息；加签后需在服务端用
timestamp和sign参数验签，否则钉钉拒绝接收；Webhook 地址形如https://oapi.dingtalk.com/robot/send?access_token=xxx - 企业微信机器人无需加签，但必须在 JSON Body 中带上
secret字段（不是 URL 参数），且Content-Type必须为application/json；Webhook 地址形如https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx - 钉钉对单条消息长度限制更严（最多 2000 字符），企业微信允许分段发送；两者都限制每分钟调用次数（钉钉约 20 次/分钟，企微约 200 次/分钟），高频提交需做队列或合并发送
- 测试时别只发一次：用
curl -X POST -H "Content-Type: application/json" -d '{"msgtype":"text","text":{"content":"test"}}' <code>Webhook地址直接调用，绕过 Git 平台验证接口是否通
如何让通知只发「有意义」的分支变动
默认 Webhook 会把所有 push 都推过来，包括文档修改、CI 配置更新等噪音。真正需要关注的是：主干合并、发布分支更新、特定目录变更。
- 在接收端（比如你写的 Node.js/Python 服务）解析
payload时，先读ref字段：GitLab 是refs/heads/main，GitHub 是refs/heads/master，Gitee 是refs/heads/dev——用ref.split('/').pop()提取分支名再比对 - 区分推送和合并：
object_kind == "merge_request"（GitLab）、action == "closed"且pull_request.merged == true（GitHub）、state == "merged"（Gitee）才是真正的合入动作 - 过滤文件变更范围：检查
commits[].added/modified数组，若只含README.md或.gitignore，可直接 return 不发通知 - 避免重复通知：GitLab 的
push事件里total_commits_count> 1 时，说明是一次批量推送，但通知仍应按单次事件聚合，不要为每个 commit 单独发一条
自建服务 vs 直接连 Webhook 的取舍
直接把钉钉 Webhook 地址填进 Git 平台的 URL 栏，看似最简，但实际几乎不可行——因为无法做任何过滤、格式化、验签或重试。
- 直接填 URL 的后果：
push到feature/xxx也发、CI 自动提交也发、甚至git commit --amend重写历史也会触发，群消息瞬间爆炸 - 自建一层轻量服务（哪怕只是 50 行 Python Flask）的价值在于：能读取
payload内容，按分支、作者、关键词（如[RELEASE]）、文件路径做条件判断，再决定是否调用钉钉/企微 API - 推荐最小可行方案：用
ngrok或cloudflare tunnel把本地服务暴露公网，开发阶段免部署；生产环境用轻量 VPS +systemd管理进程，不需要 K8s 或复杂框架 - 别跳过错误处理：Git 平台调用你的服务超时（默认 10 秒）、返回非 2xx 状态码、JSON 解析失败，都会导致 Webhook 被平台标记为失败并暂停——得在日志里留痕，否则通知突然停了根本查不到原因
真正难的不是配置按钮，而是厘清「谁在什么时候、以什么格式、向谁发什么内容」——Webhook 是管道，机器人是喇叭，中间那层逻辑才是让消息不变成噪音的关键。漏掉分支名提取、跳过验签、忽略重试机制，任何一个环节出问题，通知就断在半路。
