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

Question

我的团队使用功能分支，这些分支在某个时候从主分支中分支出来

# 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 也有关于-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 相同的缺点

我想知道如何改进这个过程。功能分支至少需要两次批准才能合并到主分支。从分支规则中删除管理员是否安全？PR，即使规模很大，是正确的出路吗？最佳实践是什么？

Answer 1

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

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

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

请注意，您为此选项提出的“缺点”可能不是什么大问题：

耗时; PR 通常会变得很大

无论你是使用 PR 还是只是推出合并，冲突仍然需要解决，合并仍然需要审查和测试。大型变更的 PR 的开销（与没有 PR 的推送相比）通常应该与单行变更的 PR 的开销相似，除了可能需要额外的签核和/或构建之外；但这些不应该增加那么多“人时间”。

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

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

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

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