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分支在这段时间内也会发生变化，因为我们会修复错误或合并其他特性分支。我们大多遵循特性分支工作流程中描述的过程。Github也有关于受保护分支的良好文档。

现在问题是，团队决定保护特性分支（包括管理员），这让我们在同步master和feature/name时只剩下以下几种选择：

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

   优点：更容易的方式（通常只需使用Github UI同步分支）。适用于解决小冲突 - git checkout feature/name；git merge master；解决冲突，提交，然后git push。

   缺点：存在某人向未受保护的分支推送的风险（即使是暂时的）；合并冲突错误和未经同行审核的代码。

2. 创建一个包括来自master的更改的特性分支PR。

   优点：所有代码都经过审核。

   缺点：耗时；PR通常非常大。

3. 根据要解决的冲突混合使用前两种方法。

   优点：对于小冲突（如changelog中的冲突），使用第一种方法；对于更大的冲突，使用第二种方法。

   缺点：对于什么是小或大冲突存在灰色地带。与选项1相同的缺点。

我想知道如何改进这个过程。特性分支需要至少两次批准才能合并到Master。将管理员从分支规则中删除是否安全？即使很大，PR是否是正确的选择？有哪些最佳实践？

- thenewjames

---

小想法：我不确定这句话是否相关：“功能分支需要至少两个批准才能合并到主分支。”因为这个问题是关于将“主分支”合并到“功能/名称”，而不是反过来。当你将“功能/名称”保护起来时，我认为你可以决定是否仍然需要那些2个批准来进行该分支的合并。 - TTT

我认为这是相关的，因为即使从方法1中存在一些错误，这些错误很可能会被两个审阅者中的一个发现。 - thenewjames

那很有道理。 - TTT

Answer 1

我理解的方式是，你最好选择方案2：始终要求将PR合并到受保护的功能分支中。这意味着有时需要在PR中包含更新的master到受保护的功能分支中。

有两种方法可以实现：

1.定期创建一个单独的master到feature/name的PR（如果存在冲突，则可能需要一个临时分支）。

2.让其中一个功能分支被PR到feature/name，并在他们的分支中包含最新的master。

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

时间消耗大；PR通常会变得非常庞大

无论你是使用PR还是直接推送合并，都必须解决冲突，并进行审核和测试。对于大型更改而言，与推送而没有PR相比，PR的开销应该基本相似，除了可能需要额外的签名或构建之外；但这些不应该增加太多的“人力时间”。

请注意，始终要求创建拉取请求才能将代码合并到受保护的功能分支中，没有例外情况，还有一个好处。当将受保护的功能分支合并回master时，审阅者将知道在功能分支上的每个更改都已经过代码审查。这样，审阅者就可以将重点放在合并后的更改上，而不必对每个单独的更改进行深入的功能、样式等审查。

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

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

最终结果相同，但您无需检查master，也不会意外使用过时的本地master副本。

- TTT