将 dev 合并到 main 分支的正确方法

我想把我的答案集中在你问题的一部分上，因为你同时问了多个问题。你可以问问自己，这个项目/团队甚至有一个开发分支是否是一个好主意。也许如果没有它，您的工作效率会更高和/或具有相同的代码质量和/或维护能力。例如，请参阅这个 SO 问题，了解拥有开发分支的好处。

关于本地与 Gitlab/Github 合并： 我总是尝试与 Gitlab 合并，因为它允许讨论更改并更轻松地将有关合并（请求）的链接发送给其他人。此外，它将允许你在合并实际发生之前更容易依赖 CI，因此只有在管道成功时才进行合并（例如，参见这个 Gitlab 文档）。

我认为解决您的问题的最佳解决方案（将提交中的更改从分支带到分支）是使用 .这使您能够在不合并或变基的情况下进行一组提交，并避免您指出的所有问题。maindevgit cherry-pickmain

看看这个指南，前段时间对我帮助很大。

你对做什么的理解几乎是正确的。可能需要调整的部分是你使用“集成”一词来表示快进，而重要的是要意识到，无论你是允许快进发生，还是强制创建合并提交，生成的文件结构都是相同的。在这两种情况下，所有提交都是“集成”的，您可以在两个分支中看到它们具有相同的提交 ID。强制合并提交会影响分支历史记录的图形。请注意，在快进合并后，分支是相同的，这意味着两个分支名称都指向相同的提交 ID。如果快进是可能的，但您习惯于创建合并提交，则其中一个分支指向合并提交，并且正如您所注意到的，它将在源分支之前进行一次提交。这就引出了您的问题：git merge --no-ff--no-ff--no-ff

但是，现在该分支落后一个提交。如何最好地解决这个问题？到目前为止，我会简单地再次合并，但这似乎很麻烦和奇怪，因为现在我的分支中还有另一个提交：devmainmaindevdev

这里有两个观察结果：

1. 实际上，如果您在 dev 上出现任何新提交之前合并并返回，那么可以快进回，并且如果您不想生成新的合并提交（带有消息“将分支 main 合并到 dev”）。如果您允许快进合并，则之后将指向与合并提交相同的提交，并显示消息“将分支 dev 合并到 main”。如果您选择用于该合并，那么您当然会创建一个新的合并提交。devmainmaindevdevdevmain--no-ff
2. 让我们假设合并提交在那里，要么是因为新的提交在两次合并之间偷偷溜进来，要么是因为你使用并强制了它。那又怎样？如果你强制合并提交（例如，默认的 Git Flow 推荐），那么是的，你将有合并提交，这意味着并且永远不会相同，这完全没问题。dev--no-ffdevmain

现在让我们来看看你的一些其他问题：

这个 SO 问题告诉我正确的方法是首先将 main 合并到 dev 中，以确保 main 分支保持干净。这是实现开发>主要合并的最佳方式吗？

这取决于你。在 Git Flow 模型中，如果出现新的提交，您通常希望尽快合并回，这样您就不会测试与将要部署的内容不同的东西。（或者更糟糕的是，如果您从临时分支或临时分支进行部署，则不会从生产中清除修补程序更改，因为它们尚未在您的分支中。因此，在合并到 .相反，如果修补程序出现在上面，您应该在不久之后将它们合并到中。然后将随时准备合并到 .mainmaindevdevreleasemainreleasemaindevdevmainmaindevdevmain

这是否受到 git fast-forward 默认合并的概念的影响？...当 dev 分支只是领先于 x 提交到 main ...合并会自动成为快进合并吗？

是的。如果可能，快进合并是默认设置。

这种行为对于将 dev 合并到 main 中是否有问题，合并时我应该使用 -no-ff 标志吗？

这没有问题。是否应该强制合并提交由您决定。有一些优点和缺点。摘自我对另一个问题的回答：

The merge (with --no-ff) forces a merge commit, and this is helpful because each PR contains the list of commits associated with just that PR, enabling you to view the first-parent history which shows all merges into the branch, and easily compare them. Another benefit of forcing the merge commit is that it's easy to revert an entire PR by simply reverting the merge commit, rather than individually reverting every commit that was in the original PR.

Note that GitLab calls a "Pull Request" a "Merge Request", so you can just substitute "MR" where you see "PR" in the above paragraph. The only con of forcing a merge commit is: If you don't care about any of those advantages just mentioned, then it adds unnecessary complexity to the resulting graph.

Lastly, you asked:

How would I then push the merge upstream after merging branches locally? Should I even merge dev and main locally or simply keep using gitlab web interface for this?

It doesn't make a difference if you don't have branch protection enabled. If you turn on branch protection/policies for your and branches (in GitLab), then you will need to use the Merge Request functionality to perform those merges. When you complete the Merge Request you can select whether you want fast-forward or to force a merge commit. If you do it locally, then you simply have to push out the branches to your remote server (GitLab), if you have permission to do it. Either way the end result is the same.devmain