合并 develop 分支到 master 不是我想象的

Question

我们使用简化版本的 Git 流程，我们的大部分工作直接进行开发，只有在发布时我们才合并回 master。

我们刚刚发布了第一个版本，因此这是我第一次将 develop 合并回 master，因为我首先在一开始创建了 master 分支，然后从它分支 develop。

我设想的是将单个提交合并回 master 分支，这样如果我稍后在一个干净的文件夹中签出 master，我只会看到原始提交和新的发布提交。相反，我在主分支历史记录中看到了 develop 分支 的完整提交历史。

我明白为什么会这样。毕竟，这些只是 2 个合并的分支，快速合并只会将 master 压缩到我的开发分支的顶端。但这不是我想象的。检查 master 分支并能够从另一个分支看到导致它的所有工作的完整历史对我来说似乎很奇怪。

我发现自己在考虑，在这种情况下，如果我们只是要将它们合并在一起，为什么我们要同时维护开发和主分支，查看相同的历史记录，并利用标签来指示已发布的提交（我们是一家小公司）？

这是大多数人的做法吗？这是“正确的”吗（我知道这是一个很重要的问题）？还是人们对待 master 分支的方式与所有其他分支不同，并且可能进行压缩合并或 no-ff 合并以创建更清晰的 master 分支历史记录？

Answer 1

如果您使用的是 gitflow-inspired 工作流程，那么您可能希望在合并时使用 --no-ff 选项。

git checkout master
git merge --no-ff dev

这会强制合并提交，即使 fast-forward 是可能的，所以你得到

--- O ----------- M <--(master)
     \           /
      x -- x -- x <--(dev)

即便如此，默认情况下大多数 git 命令仍会显示详细的历史记录（包括 dev 提交），但您可以使用 --first-parent 选项覆盖它。

git log --first-parent master

也就是说，还有其他原因可以让您将 master 和 dev 分支分开，即使您最终要 fast-forward dev 进入 master。原因之一是确保 master 始终是最新发布的状态。您可以使用版本标签来代替，但也许您想要一个始终表示“最新版本”的名称，and/or 也许您希望最新版本是什么默认情况下在新克隆中签出，或者您的团队和项目特有的其他内容。

合并 develop 分支到 master 不是我想象的

Merging develop branch into master is not what I envisioned

git

merge

branch

master