简化Git工作流优化咨询：变基报错、分支权限及流程合理性

我们团队有2-3名开发者负责WordPress项目，采用简化Git工作流，核心分支包括development、staging、production：

• 推送核心分支会触发自动构建部署至对应远程服务器
• 简单需求/BUG修复直接在development分支开发；复杂/实验性功能从development拉出feature分支，完成后合并回development
• 内部测试通过QA后，执行以下命令将代码合并到staging分支：

  git checkout staging; git pull; git merge development; git push
  

  staging仅接收来自development的代码，供客户审核
• 客户审核通过后，执行发布检查清单，再通过以下命令推送到production分支：

  git checkout production; git pull; git merge staging; git push
  

  production仅接收来自staging的代码，每月为每个客户推送一次生产版本

现有流程存在两个痛点：

• 大量合并提交导致提交历史杂乱难读
• 存在误提交至错误分支的风险

1. 希望从合并下游分支切换为变基，但执行git checkout staging; git rebase development时出现数月甚至数年前提交的合并错误，这是否因从合并切换为变基导致？若坚持合并是否可避免此问题？（注：不介意改写staging和production的提交历史，因为这些分支仅接收来自上游分支的代码）
2. 能否设置分支仅接受来自上游分支的合并或变基推送，拒绝其他提交？
3. 当前工作流是否存在问题？尚未掌握变基的优势，系统虽能运行，但偶尔会遇到棘手的Git问题却不知原因。

问题1解答 #

是的，这类合并错误确实是从合并切换为变基导致的。之前staging通过合并development更新，分支历史里堆积了大量合并节点；当突然对staging执行变基时，Git会尝试把staging上的所有提交（包括历史合并产生的提交）重新应用到development的最新提交上，这就触发了大量历史冲突。

如果坚持用合并，确实能避免这类问题——合并只会处理两个分支当前的最新差异，不会改写历史提交，自然不会触发旧冲突，但也无法解决提交历史杂乱的问题。

既然你不介意改写staging和production的历史，建议做一次一次性的历史清理：

1. 确保development是最新状态：git checkout development; git pull
2. 基于development创建全新的staging分支：git checkout -b staging-new development
3. 替换远程staging分支：git push origin staging-new:staging --force
4. 后续所有staging的更新都用变基：git checkout staging; git rebase development
   这样能彻底清除历史合并节点，后续变基不会再触发旧冲突。

问题2解答 #

可以通过分支保护规则实现：

• 如果用GitHub/GitLab等托管平台：在仓库设置的分支保护选项中，针对staging和production分支开启以下规则：
  • 禁止直接推送，要求通过PR合并
  • 限制合并来源仅允许指定分支（比如staging只允许合并development，production只允许合并staging）
  • 若需要改写历史，可开启允许指定用户强制推送，否则禁止强制推送
• 如果是自建Git服务器（比如Gitea、Gitolite）：可以编写pre-receive钩子脚本，校验推送的提交来源，拒绝不符合规则的推送——比如检查推送的分支是否仅包含来自上游分支的提交，不符合则返回错误阻止推送。

问题3解答 #

当前工作流本身没有大问题，适合小团队的WordPress项目，但可以做一些优化来减少Git问题：

变基的核心优势 #

变基的核心价值是整理出线性、干净的提交历史，让分支历史像一条直线，更容易追溯问题。适合在feature合并到development、development同步到staging这类场景使用——这些分支属于团队内部协作或预发布分支，历史可改写。

工作流优化建议 #

1. 规范feature分支的合并方式：feature分支完成后，先用git rebase development把feature的提交变基到development最新节点，再合并（或直接推送），避免development产生过多合并提交
2. 统一分支更新方式：既然不介意改写staging和production的历史，就固定用变基同步上游分支，不要在合并和变基之间切换，避免历史混乱
3. 增加本地分支校验：给团队配置Git钩子（比如pre-push hook），在推送前检查当前分支是否允许推送到目标远程分支，避免误提交
4. 定期清理历史：每季度或每半年清理一次老旧的feature分支，减少仓库体积和历史复杂度

内容的提问来源于stack exchange，提问作者Slam