git - git-flow 是否应该在 master 上看到比开发更压缩的历史记录？

Question

请原谅我的无知，但我正试图将 "git-flow"将模型付诸实践(手动，不使用 git-flow 工具集)。

我发现一个有趣的概念是，会有一个主分支，每个提交都是一个真正可行的版本。因此，您在 master 上标记了 v1.0.0 提交，然后是 v1.1.0 标记，在查看 master 时，这是一个不错的 2 提交长日志。但是随后您准备好发布 v1.2.0 并且您的 develop 分支有 1000 个中间提交，但是您准备好退出并按下按钮说 “好吧，发布了时间”。

我的目标是在主时间轴上添加第三次提交。我可以看到 --squash 选项可以让您向 master 添加一个提交，因此您查看 master 日志并看到您的三个提交:v1.0.0、v1.1.0 和 v1。 2.0。尽管 develop 分支可能冗长冗长，但压缩会让您了解 master 的整洁历史，其中每个版本都是官方发布......没有机会捕获中间开发提交!

它有效，但令我困扰的是，在网络图中查看会产生“断开连接”的提交。 Git 理解将这个压缩的第三次提交与开发分支的所有数千个添加联系起来没有明显的关系。它似乎是单独漂浮的，不像 git-flow 图是手绘的，总是指向事物。

获得“merge 箭头”(也称为多个父项)的其他 merge 选项似乎具有与中间提交建立连接的副作用。所以突然间 master 不仅仅是这 3 个有福的提交......它已经扩展到包括所有这 1000 个开发提交的完整历史。有点似乎违背了目的，如果 master 的点是一个只包含可发布版本的分支......但是突然之间每个中间状态都有一个对 master 的提交。 1003 而不是 3 个主提交。

Git 可视化有点险恶，因为它掩盖了分支中的重复。所以我在 git-flow 上看到的图表是图片，而不是 git log 等的终端打印输出。我不确定人们对这样的声明有什么期望，比如说 master 只包含可发布的版本。

长话短说:我找不到在发布点保留 develop 和 master 之间“箭头式”关系的选项，除非它们带有完整的提交历史记录。如果我查看有很多箭头的 git 流程图，我会担心吗？在我概述的场景中，我应该查看主历史记录并查看 merge 的每个中间开发版本和 1003 提交历史记录，还是 3 提交历史记录？

Answer 1

Is git-flow supposed to see a more compressed history on master than develop?

没有。基本上(忽略修补程序和发布候选分支):master = develop + merge commits.

In the scenario I outlined, should I look at the master history and see every intermediate develop version that was merged and a 1003 commit history, or the 3 commit history?

这有点取决于您请求的主历史的特定 View 。但一般来说，您应该会看到 1003 次提交的历史记录。

git-flow 的历史

更一般地说，并采纳您的一些隐含假设:使用 git-flow 来保存 和连接 提交历史。因此，与 --squash merge 是绝对不行的，因为它(如您已经观察到的那样)不会将 master 与导致其发布的开发线联系起来状态。恰恰相反，您绝对希望确保对 master 的每次提交都是始终 merge 提交——与--squash 所做的完全相反。这就是为什么您总是在 git-flow 中使用 --no-ff merge 。 (在现代版本的 Git 中，您可以将 merge.ff 选项设置为 false 并且不再担心忘记 --no-ff。)

另请注意 Vincent Driessen 的 original git-flow article 确实检查了这些问题。

扁平化的危险

请注意，扁平(线性) View 必须使用展平策略将完整图形简化为线性外观。这种扁平化可能会造成混淆。

作为要考虑的示例，请考虑示例图中的第二个青色节点和第五个黄色节点。现在假设，第二次青色提交是在第五次黄色提交之后的一天进行的。

---1-----------------7----------10~~ master
    \              /           /
     2---3---4---5--6-----8---9~~~~~ develop

(我知道在 git-flow 的上下文中这是一个相当人为的例子。没有发布候选分支，通过将其 merge 到 master 来发布“第二个最新”提交是非常不寻常的。)

如果您现在从 master 的角度扁平化这段历史，您希望它如何表示？如果你主要使用时间顺序，那么给你:

   10  9  8  7  6  5  4  3  2  1

(此时间顺序是默认的 git log 和 Github 的“提交” View 将为您提供的。)

或者您希望通过 merge 提交整合的所有提交彼此相邻出现吗？

   10  9  8  6  7  5  4  3  2  1

(这种“拓扑”排序就是 git log --topo-order 会告诉你的。)

或者您只想提交来自一个祖先的提交？

   10  7  1

(这最接近于询问“只显示对 master 的直接提交”，这似乎是您期望看到的内容的一部分。在 git-flow 设置中，git log --first-parent 在 master 上会显示这个 View 。)