问题描述
关键点： 我想确保在创建软件版本的过程中不会遗漏任何提交和更改，尤其是如果某些提交由于先前的测试而被精心挑选或重新设置了基础。
编辑：很明显，最后-一个人必须判断这些提交是否正确。但是，列出未包含的提交列表会有所帮助，我希望可以从git中获取。
我们尝试遵循Git-Flow工作流程来开发中小型（几万个LOC）嵌入式项目。为此，核心团队中有5个人。我们有一个Bitbucket / Jira后端，用于跟踪问题并审查请求请求。
我们有两个分支机构：
-
master：已发布并经过测试的固件 -
develop：主要的集成分支，此处的代码可以编译和测试，但尚未发布 -
feature/...：很多功能分支 -
bugfix/...：几个错误修正分支 -
release/...：发布准备工作，这是开发人员和开发人员之间的“安全”屏障，可以进行最终调整和最终测试
理想情况下，为一个问题凭单创建一个分支，使用命名方案包括问题的密钥和描述，以进行适当的跟踪和追溯。
想象一下这种情况：
-
在Jira中创建了ID为“ FW-5”的功能部件请求票证“添加FIR滤波器模块”，并导致了功能分支“功能/ FW-5-add-fir-filter-filter-module”在相应的git仓库中。开发进展顺利，该模块即将准备就绪。拉动请求可能已经开放，可以让同事审查此模块。
-
然后出现第二张标签：“添加10 Hz低通滤波器”。显然，这取决于FW-5，因为尚未对拉动请求进行审查，因此尚未开发。那就是说，我们必须从“功能/ FW-5-add-fir-filter-filter-module”分支，而不是develop。
-
管理器进入并希望即时释放当前状态，包括10 Hz滤波器。现在必须是现在，因为测试机中的一个时隙是偶然获得的。因此，我们需要编译来自development的预发行版（因为与此同时可以集成其他一些东西）和我们的两个功能分支。我将从开发开始，从那里创建发行分支，通过
git rebase集成两个功能分支，最终解决冲突，增加版本号并将其刷新到硬件。 -
一切正常，测试成功。预发行版保持不变，并且可能会进行进一步开发。然后是时候发布“真实”版本了。从步骤3）我们知道，手工制作的预发布效果很好。但是，两个功能提取请求必须集成在一起才能以我们在预发行版中进行的相同方式正确开发。包括以相同的方式解决最终的合并冲突。这就是我努力的重点。
问题： 如何确保以完全相同的方式将预发行版中所做的更改集成到发行版中？我无法以1：1的比例比较文件内容，因为与此同时，develop进一步发展，并且由于开发中的进一步提交，文件的外观可能有所不同。
我已经阅读了git branch --no-merged和一些git rev-list的想法，但是这些想法在提交SHA上起作用。因此，从预发行版本中重新定位的部分将显示为未集成。
git cherry -v是否正确？它说（请参阅：https://linux.die.net/man/1/git-cherry）
分支点之间的每个提交的变更集（或“ diff”）与分支点和之间的每个提交的比较集。将提交与从git patch-id程序获得的补丁ID进行比较。
...
由于git cherry比较更改集而不是提交ID（sha1），因此您可以使用git cherry来查找是否在其他提交ID下应用了您在本地进行的提交。例如，如果您通过电子邮件提供补丁程序，而不是直接推送或提取提交，则会发生这种情况。
听起来不错，尤其是最后一点，但是我不确定它是否正确理解。
是尚未发现的正确工具吗？如果是，为什么我找不到关于git cherry的信息？这是一个杀手tool。
如果没有-遗失的地方在哪里？合并冲突又是怎么回事：）
后续问题
- 从父要素分支（第2步）分支好吗还是有点臭？
- 在3）中调整基础是正确的方法吗？还是您更愿意使用合并或自动选择？
- 子级拉取请求应该合并回父级还是直接发展？
- 您会看到哪些替代方案？我知道最好先完成拉取请求并将其正确集成以进行开发，但这有时是行不通的。
- 您是否允许工作流程中的从属功能分支？整合拉取请求后，您是否执行命令？
- 如果允许使用依赖功能分支，则还必须允许对这些功能分支进行重新设置，以摆脱子级中的父提交，对吗？而且，在父级集成之后，您必须在开发基础上重新设置子级。还是您先将子级合并回其父级，这意味着所有子级拉取请求都必须先关闭。
谢谢！
解决方法
不是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
从技术角度来看，您可以执行您要询问的任务，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或cherry-pick期间解决冲突时，它将得到误报。评估不包括提交的原因将是解释输出过程的一部分。
关于为什么您对此了解不多...嗯，我知道您相信这是一个杀手tool，但是实际上我不能说我看到过许多想要解决这个问题的项目这样。
一天结束时，没有人关心已应用哪些提交。他们关心蠕虫软件的功能。如果您的测试足够好，可以告诉您软件是否正常运行，那么就不会错过重要的提交，如果错过了某个提交，则会有解释为什么无关紧要的原因。如果您的测试不够好，那么确保所有提交都得到保证的意义并不大。
我还要指出，gitflow通常不依赖于很多提交复制。也许您的工作流是gitflow的某种变体，或者可能只是在术语上存在分歧，但是我看不到在我称之为gitflow的工作流中这将是一个问题。
最后，要解决您的大多数后续问题：
是否/何时从“父分支”创建分支[1]是项目工作流程的决定；我们不能说它是“好”还是“坏”。就是说，gitflow记录了规则，这些规则定义了分支的创建位置和合并位置。如果gitflow是您的模型，那么这些规则是唯一可以说明给定合并是否如您所说的“臭”的外部来源
[1]顺便说一句，“父分支”不是git中存在的概念。我知道您问这个问题的意思，但是以这种方式考虑分支机构可能会产生误导。