Git - 使受保护的功能分支与主分支保持同步

Git - Keeping protected feature branch in sync with master

我的团队使用在某些时候从 master 分支出来的特性分支

# make sure the local version of master is up to date
git checkout master
git fetch origin 
git reset --hard origin/master

# create a new branch
git checkout -b feature/name

在我们开发新功能时，这些功能分支可以存在几个月，但随着我们解决错误或合并其他功能分支，master 也会在该时间跨度内发生变化。

我们主要遵循 feature-branch-workflow. Github also has good documentation about-protected-branches 中描述的流程。

现在，问题是团队决定保护功能分支（包括管理员），让我们在同步 master 和 feature/name 时有一些选择：

  1. 暂时删除分支保护规则，以便我们可以将 feature/name 更新为 master

    优点：更简单的选项（通常只使用 Github UI 同步分支）。很好解决小矛盾——git checkout feature/name； git merge master;解决冲突、提交和 git push

    缺点：有人推到不受保护的分支的风险（即使是暂时的）；合并冲突错误和未经同行评审的代码

  2. 为功能分支创建一个 PR，其中包含来自 master

    的更改

    优点：所有代码都经过审查

    缺点：耗时； PR 通常会变得很大

  3. 两者结合，具体取决于要解决的冲突

    优点：使用方法 1 处理小冲突（例如变更日志中的冲突），使用方法 2 处理更大的冲突

    缺点：小冲突或大冲突的灰色地带。与选项 1

    相同的缺点

我想知道如何改进这个过程。 Feature 分支至少需要两次批准才能合并到 master。从分支规则中删除管理员是否安全？ PR，即使很大，也是可行的方法吗？最佳做法是什么？

据我了解，您最好的选择是#2：始终要求将 PR 提交到受保护的功能分支中。这意味着您有时可能需要将 PR 中更新的 master 包含到受保护的功能分支中。

有两种方法可以做到这一点：

  1. 定期创建 master 的单独 PR 到 feature/name（如果存在冲突，可能需要单独的临时分支）。
  2. 让 PR 进入 feature/name 的功能分支之一在其分支中包含最新的 master。

请注意，您针对此选项提出的“缺点”可能没什么大不了的：

time-consuming; PRs usually get very big

不管你是用PR还是直接push merge，冲突还是要解决，merge还是要review和测试。用于大型更改的 PR 的开销（与没有 PR 的推送相比）通常应该与用于单行更改的 PR 的开销相似，除了可能需要额外的签核 and/or 构建；但是那些不应该增加那么多的“人时”。

请注意，始终要求 PR 将代码无一例外地放入受保护的功能分支还有另一个优点。当需要将受保护的功能分支合并回 master 时，审阅者会知道功能分支上的 每个 更改都已经过代码审查。这样审阅者就可以专注于合并后的变化，而不必对功能、样式等的每个单独变化进行深入审查。

提示：我告诉开发人员通常要避免签出 master 并删除他们的本地副本，因为您实际上几乎不需要它。几乎每个用 master 运行 的命令都可以用 origin/master 代替。您可以将用于创建功能分支的 4 个命令简化为这 2 个命令：

git fetch
git checkout -b feature/name origin/master --no-track

最终结果是相同的，但您永远不必费心查看 master，而且您也不会不小心使用本地 master.

的过时副本