在集成到主之前测试依赖的 git 功能分支 - 处理预发布

Question

关键点： 我想确保在创建软件版本的步骤中没有遗漏任何提交和更改，特别是如果某些提交由于之前的测试而被精心挑选或重新设置基准。

编辑：很明显——最终——人类必须判断提交是否正确。但是有一个未包含的提交列表会有所帮助，我希望从 git 中得到它。

我们尝试遵循Git-Flow 工作流程来开发中小型（几个 10k LOC）嵌入式项目。为此，核心团队中有 5 人。我们有一个 Bitbucket/Jira 后端来跟踪问题和审查拉取请求。

我们有几个分支：

• master：发布并测试固件
• develop: 主集成分支，这里的代码可编译和测试，但尚未发布
• feature/...: 很多功能分支
• bugfix/...: 几个错误修复分支
• release/...：发布准备，开发和主控之间的“安全”屏障，可以进行最终调整和最终测试

理想情况下，为一张问题单创建一个分支，使用一种命名方案来包含问题的关键和描述，以便进行适当的跟踪和追溯。

想象一下这种情况：

1. 在 Jira 中创建了一个 id 为“FW-5”的功能请求票“添加 FIR 过滤器模块”，并导致相应的功能分支“feature/FW-5-add-fir-filter-filter-module” git 存储库。开发进展顺利，模块即将准备就绪。可能已经开放了一个拉取请求，以让同事审查此模块。

2. 然后第二张票进来了：“添加 10 Hz 低通滤波器”。这显然取决于 FW-5，它尚未进入开发阶段，因为拉取请求尚未经过审查。这意味着，我们必须从“feature/FW-5-add-fir-filter-filter-module”分支而不是从develop分支。

3. 经理进来并希望及时释放当前状态，包括 10 Hz 滤波器。一定是现在，因为偶然出现了测试机器中的一个时间段。所以我们需要从开发中编译一个预发布版本（因为同时可以集成一些其他的东西）和我们的两个特性分支。我将从开发开始，从那里创建一个发布分支，通过git rebase 集成两个功能分支，最终修复冲突，增加版本号并将其闪存到硬件。

4. 一切顺利，测试成功。预发布保持原样，可能会进行进一步的开发。然后是“真正”发布的时候了。从第 3 步我们知道，手工制作的预发行版运行良好。然而，这两个功能拉取请求必须集成才能正确开发，就像我们在预发布中所做的那样。包括以相同的方式修复最终的合并冲突。这就是我正在努力解决的问题。

问题： 如何确保在预发布中所做的更改以完全相同的方式集成到发布中？我无法 1:1 比较文件内容，因为与此同时，develop 已经进一步发展，并且由于 develop 中的进一步提交，文件可能看起来有所不同。

我读过关于 git branch --no-merged 和一些 git rev-list 的想法，但这些都是在提交 SHA 上运行的。因此，预发布版本中重新设置的部分将显示为未集成。

git cherry -v 是正确的方法吗？它说（见：https://linux.die.net/man/1/git-cherry）

分支点之间的每个提交的变更集（或“差异”）与分支点和 .将提交与从 git patch-id 程序获得的补丁 id 进行比较。

...

因为 git cherry 比较的是变更集而不是提交 id (sha1)，所以您可以使用 git cherry 来确定您在本地进行的提交是否已在不同的提交 id 下应用。例如，如果您通过电子邮件提供补丁而不是直接推送或拉取提交，就会发生这种情况。

这听起来很棒，尤其是最后一点，但我不确定它是否理解正确。

如果还没有集成任何应该成为发布的一部分的东西，那么这是找出正确的工具吗？如果是，为什么我发现关于git cherry 的信息这么少？这是一个杀手锏。 如果没有 - 缺失点在哪里？什么是合并冲突:)

后续问题

• 从父功能分支（第 2 步）分支是否正常或有点臭？
• 3) 中的变基是正确的方法吗？还是您更愿意使用合并或樱桃挑选？
• 子拉取请求应该合并回父级还是直接开发？
• 您会看到哪些替代方案？我知道最好先完成拉取请求并正确集成以进行开发，但有时这不起作用。
• 您的工作流程中是否允许依赖功能分支？集成拉取请求后，您会执行命令吗？
• 如果允许依赖特性分支，您还必须允许这些特性分支的变基以摆脱子级中的父提交，对吗？在父级集成后，您必须将子级重新定位到开发之上。或者您是否首先将子级合并回其父级，这意味着必须首先关闭所有子级拉取请求。

谢谢！

Answer 1

不是 100% 的答案，但对于评论来说太长了。我希望它能提供一些有用的提示。

假设你有类似的历史

*----------------  master
\       \-*---*--  develop
 \         \-----  feature
  \*----*--------  bugfix
         \----*--  release

提交用* 表示。如果我们想合并，例如释放到主人， 我们做merge --no-ff --no-commit release，图片看起来像

C1                   C2
*--------------------*  master
\       \-*---*-----/   develop
 \         \-------/    feature
  \*----*---------/     bugfix
         \----*--/      release

--no-ff 确保我们可以比较原始版本之间的差异 状态C1 和合并提交之前的状态C2。 如果C2 中的更改很关键，我们只需检查一个列表以确保所有更改都可以在C1 和C2 之间的差异中看到

Answer 2

从技术角度来看，您可以执行您所询问的任务，git cherry 可以成为该解决方案的一部分。因为git cherry比较特定的分支，我会把它和git for-each-ref结合起来

git for-each-ref --format='%(refname)' |while read ref; do git cherry -v master $ref; done |grep ^+

因为它在补丁 ID 上运行，所以如果在原始 rebae 或樱桃挑选期间解决冲突，它会得到误报。评估未包含提交的原因将是解释输出过程的一部分。

至于为什么你没有听到很多关于这个的消息......好吧，我理解你认为它是一个杀手级工具，但在实践中我不能说我见过很多想要解决这个问题的项目这边。

一天结束时，没有人关心应用了哪些提交。他们关心软件的功能。如果您的测试足以告诉您软件的行为是否正确，那么就不会错过重要的提交，如果错过了提交，则会解释为什么它不重要。如果您的测试不够好，那么确保所有提交都得到考虑并没有多大意义。

我还要注意 gitflow 通常不依赖于大量的提交复制。也许您的工作流程是 gitflow 的一些变体，或者只是对术语的分歧，但我看不出这在我称之为 gitflow 的工作流程中会成为一个问题。

最后，解决您的大部分后续问题：

是否/何时从“父分支”[1] 创建分支是项目工作流程决定；我们不能说它是“好”还是“坏”。也就是说，gitflow 已经记录了分支的创建位置和合并位置的规则；如果 gitflow 是您的模型，那么这些规则是唯一可以判断给定合并是否像您所说的“臭”的外部来源

---

[1] 顺便说一句，“父分支”不是 git 中存在的概念。我知道你问这个问题的意思，但以这种方式考虑分支可能会产生很大的误导。