关于 git flow continuously merge bugfix branch into dev branch 的问题
A problem about git flow continously merge bugfix branch into dev branch
gitFlow image
我对从 bugfix 分支不断合并到 gitflow 的 dev 分支感到困惑。想想这种情况，如果我合并commit A和B到dev分支时有冲突，我就解决了。然后我在 bugfix 分支中做了几次提交，现在如果我将 bugfix 分支合并到 dev 分支中，我是否需要解决由提交 A 和 B 又是？
我知道git找到相同的祖先提交来执行三向比较，如果我猜对了，相同的祖先提交将永远是黄色提交，所以我需要再次解决相同的冲突再次将 bugfix 合并到 dev 时，这是不合理的。我也验证了我的猜测，但是结果不一致
谁能帮帮我，非常感谢！
更新：我的测试细节：
log graph
测试显示 git 合并算法看起来可以记住我在提交时的解决 D 并且有时会自动解决冲突。我知道可能很难解释测试，但如果有人能告诉我 git 合并算法做了什么，我将不胜感激。
在merge中，构成正在合并的分支历史的单个修订并不重要。 Git 会找到最后一个共同祖先（在 recursive 策略中不是真的，但是，唉，很好解释）并且会比较 分支的提示 被合并这次修订。如果这些分支与共同祖先的差异不能合并在一起，那么就会发生冲突（或许多冲突）。如果 A 或 B 在任何分支的历史记录中的某个时刻产生了冲突，那么在那个时刻实际上是无关紧要的。
你画错了。必须没有长期存在的错误修复分支。您将 C 合并到 dev 以形成 D，现在您 删除 该分支。如果有人想做E，它从dev分支，而不是C。
（或者在每次合并到 dev 之前将 dev 反向合并到 bugfix。）
gitFlow image
我对从 bugfix 分支不断合并到 gitflow 的 dev 分支感到困惑。想想这种情况，如果我合并commit A和B到dev分支时有冲突，我就解决了。然后我在 bugfix 分支中做了几次提交，现在如果我将 bugfix 分支合并到 dev 分支中，我是否需要解决由提交 A 和 B 又是？
我知道git找到相同的祖先提交来执行三向比较，如果我猜对了，相同的祖先提交将永远是黄色提交，所以我需要再次解决相同的冲突再次将 bugfix 合并到 dev 时，这是不合理的。我也验证了我的猜测，但是结果不一致
谁能帮帮我，非常感谢！
更新：我的测试细节： log graph
测试显示 git 合并算法看起来可以记住我在提交时的解决 D 并且有时会自动解决冲突。我知道可能很难解释测试，但如果有人能告诉我 git 合并算法做了什么，我将不胜感激。
在merge中，构成正在合并的分支历史的单个修订并不重要。 Git 会找到最后一个共同祖先（在 recursive 策略中不是真的，但是，唉，很好解释）并且会比较 分支的提示 被合并这次修订。如果这些分支与共同祖先的差异不能合并在一起，那么就会发生冲突（或许多冲突）。如果 A 或 B 在任何分支的历史记录中的某个时刻产生了冲突，那么在那个时刻实际上是无关紧要的。
你画错了。必须没有长期存在的错误修复分支。您将 C 合并到 dev 以形成 D，现在您 删除 该分支。如果有人想做E，它从dev分支，而不是C。
（或者在每次合并到 dev 之前将 dev 反向合并到 bugfix。）