主干分支（main）不能向特性分支合并，否则会污染变更边界、破坏可测试性与发布控制；正确做法是用git rebase origin/main将特性提交重放到最新主干之上，保持线性历史和单一意图。
主干分支（main）不能也不应该向特性分支持续合并——这是反模式，会污染特性分支的变更边界，破坏可测试性与发布控制。
为什么不能用 git merge main 到 feature 分支
开发者常误以为“同步最新代码”就要把 main 合并进自己的 feature/login，结果导致：
- 特性分支混入其他未关联功能的提交，历史不可追溯
- CI 构建失败原因难定位：是自己改的逻辑错，还是刚从
main合并进来的某次重构引发的？ - 后续
git revert或回滚变得危险——你 revert 的可能是一整段来自main的无关改动 - PR 审查时 diff 膨胀严重， reviewer 无法聚焦真正新增的变更
正确做法：用 git rebase 同步主干变更
目标不是“把 main 的内容搬进来”，而是让 feature 分支的提交“站在最新的 main 之上”。这保持提交线性、干净、语义明确：
- 执行前确保已在
feature/login分支，且本地无未提交修改 -
git fetch origin拉取远程最新状态 -
git rebase origin/main将本分支所有提交“重放”到origin/main最新提交之后 - 若出现冲突，解决后
git add . && git rebase --continue - 强制推送（仅限尚未公开的私有特性分支）：
git push --force-with-lease origin feature/login
注意：--force-with-lease 比 --force 安全，它会拒绝覆盖他人已推送的新提交。
GitHub Actions Secret Exposure Audit
下载
审计 GitHub Actions 工作流文件的密钥泄露风险，例如 pull_request_target 密钥使用、密钥回显命令及未固定版本的 Action 密钥传递。
何时该用 git merge 而非 rebase
仅在以下场景才考虑把 main 合并进 feature：
- 该 feature 分支已被多人协作开发，且已推送到远程（此时
rebase会扰乱他人本地历史） - 你需要显式记录“在此刻集成主干”的决策点（例如灰度发布前的基线对齐），这时应新建一次 merge 提交，而非 rebase
- 团队明确定义了“集成点提交”为发布流程一环（如配合 CI 自动打 tag）
即便如此，也建议在 merge 前先 git checkout main && git pull，再 git checkout feature/login && git merge main，避免意外基于过期的本地 main 合并。
Trunk-Based Development 下的替代方案
TBD 模式根本不鼓励长期 feature 分支。更健壮的做法是：
- 拆小任务：单个
feature分支生命周期 ≤ 1 天 - 用特性开关（
feature flag）隔离未完成逻辑，而非靠分支隔离 - 每日至少一次
git pull origin main && git rebase origin/main，保持本地提交紧贴主干 - CI 验证通过后立即合入
main，不积压
真正的难点不在命令怎么敲，而在于能否守住“feature 分支只承载单一意图”的边界——一旦开始往里塞同步、修复、调整，它就不再是 feature，而成了临时垃圾堆。
