从已合并分支提交PR是否为最佳实践？分支修改方案咨询

两种方案的适用场景 #

1. 从master新建分支提交PR（常规推荐） #

• 这是团队协作中的标准操作，优势在于：
  • 原feature分支已完成合并使命，复用会让仓库分支结构混乱，其他成员可能误以为该分支已归档，增加后续维护成本。
  • 基于最新master创建分支，能确保修改基于当前代码的最新状态，避免潜在冲突（尤其master在你合并后有新提交时）。
  • 新分支可以用更清晰的命名，比如fix/feature-user-profile-typo，明确传达修改目的，方便代码审查和历史追溯。

2. 继续在原feature分支修改提交PR（仅特殊场景可用） #

• 只有同时满足以下条件时，才考虑这种方式：
  • 原feature分支合并到master后，master没有任何新提交（即master当前HEAD就是你feature分支的最后一次提交）。
  • 团队有明确约定允许复用已合并分支，且所有成员都知晓这个情况。
  • 修改极其微小，比如仅改错别字、调整单行注释这类绝对不会引发冲突的内容。

已合并分支再次提交PR是否属于良好实践？ #

不属于常规的良好实践，核心原因如下：

• 分支历史混乱：已合并分支在协作流程中通常被标记为“已完成”，复用它会让仓库的分支用途变得模糊，后续排查问题时难以追溯分支的演进过程。
• 冲突风险高：如果master在你合并后有其他提交，原feature分支的代码是旧版本，直接修改再提PR大概率会出现冲突，解决冲突的成本反而更高。
• 协作误解：其他成员看到已合并分支又有新提交，可能会困惑该分支是否应该被废弃，或是误以为之前的合并存在问题，额外增加沟通成本。
• 维护难度大：后续若需要回滚原feature分支的修改，复用的分支因包含合并后的新修改，会让回滚操作变得复杂。

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