Git - 使 protected 功能分支与主分支同步

Question

我的团队使用在某些时候从 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

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

我们主要遵循 feature-branch-workflow 中描述的流程. Github 也有很好的文档 about-protected-branches .

现在，问题是团队决定保护功能分支(包括管理员)，在同步 master 和 feature/name 时留给我们一些选择:

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

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

   缺点:有人推到不 protected 分支的风险(即使是暂时的)； merge 冲突错误和未经同行评审的代码

2. 为包含来自 master 的更改的功能分支创建 PR

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

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

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

   优点:使用方法 1 处理小冲突(例如变更日志中的冲突)，使用方法 2 处理更大的冲突

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

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

Answer 1

根据我的理解，您最好的选择是#2:始终要求 PR 进入 protected 功能分支。这意味着您有时可能需要将 PR 中更新的 master 包含到 protected 功能分支中。

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

1. 定期为 master 创建一个单独的 PR 到 feature/name 中(如果存在冲突，可能需要一个单独的临时分支)。
2. 让其中一个功能分支获得 PR'd into feature/name 在他们的分支中包含最新的 master。

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

time-consuming; PRs usually get very big

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

请注意，始终要求 PR 将代码毫无异常(exception)地放入 protected 功能分支还有另一个优势。当需要将 protected 功能分支 merge 回 master 时，审查人员将知道功能分支上的每个更改都已经过代码审查。这样，审阅者就可以专注于 merge 带来的变化，而不必深入审视功能、样式等方面的每个单独变化。

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

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

最终结果是相同的，但您永远不必费心检查 master，而且您也不会意外使用本地 master 的过时副本。