时间戳

首页 > 解决方案 > Git - 使受保护的功能分支与主分支保持同步

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

问题描述

我的团队使用在某些时候从 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 也有关于保护分支的良好文档。

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 相同的缺点

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

标签： gitgithubversion-control

解决方案

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

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

  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。

推荐阅读