我在一家公司工作，我们决定要更正确地使用 git。我负责将开发分支集成到主分支中，我对如何在不同场景下正确合并感到困惑。
我们现在的工作方式：开发人员只需在dev分支上重新调整他们的功能分支即可。完成后，他们将向dev分支提交合并请求。然后，我会检查代码（我们是一个小团队），并接受合并请求。之后他们只需删除功能分支即可。当dev分支经过正确测试后，我会在 GitLab 中创建一个到主分支的合并请求，将其分配给我自己并批准它。这会在main分支上创建一个提交：
将分支“dev”合并到“main”
然而，现在该dev分支落后了一次提交main。我该如何最好地解决这个问题？到目前为止，我只是简单地再次合并main，dev但这看起来很麻烦而且奇怪，因为它们现在是我dev分支中的另一个提交；
将分支“main”合并到“dev”
我也可以在 main 上对 dev 进行 rebase，但我了解到“你永远不能对公共分支进行 rebase”
这个问题告诉我正确的方法是首先将 main 合并到 dev 中，以确保 main 分支保持干净。这是实现合并的最佳方式吗dev --> main？
这是否受到 git fast-forwards 默认合并这一概念的影响？我读到，当从当前分支尖端到目标分支存在线性路径时，就会发生快进合并。这意味着，当合并时dev分支只是在x提交 to之前main，并且同时没有对 main 进行提交（这在我们的工作中很常见，因为我们技术上只提交 from main）dev，合并将自动进行快进合并？这种行为对于合并dev到来说是否有问题main，-no-ff合并时是否应该使用该标志？
如果我理解正确，则快进合并会将提交集成dev到分支中main，而--no-ff合并会导致合并始终创建一个新的提交对象，即使可以通过快进执行合并（来源：This SO Question）。这是否意味着当 dev 只是提前提交到 main 时， ff 合并不会创建提交x？在本地合并分支后，我将如何将合并推向上游？我是否应该在本地合并 dev 和 main，或者只是继续使用 gitlab Web 界面来实现此目的？
不用说，我对这一切感到非常困惑。如果有人能解决问题那就太好了。
你对它的理解git merge --no-ff几乎是正确的。可能需要调整的部分是您对“集成”一词的使用只是为了快进，而重要的是要认识到，无论您允许快进发生，还是使用--no-ff强制创建合并提交，生成的文件结构都是完全相同的。在这两种情况下，所有提交都是“集成的”，您可以在两个具有相同提交 ID 的分支中看到它们。强制合并提交会影响分支历史记录的图表。请注意，快进合并后，分支是相同的，这意味着两个分支名称都指向相同的提交 ID。如果快进是可能的，但您用来--no-ff创建合并提交，则其中一个分支指向合并提交，并且正如您所注意到的，将是源分支之前的一个提交。这引出了你的问题：
然而，现在该
dev分支落后了一次提交main。我该如何最好地解决这个问题？到目前为止，我只是简单地再次合并main，dev但这看起来很麻烦而且奇怪，因为它们现在是我dev分支中的另一个提交：
这里有两个观察结果：
dev到main，然后在任何新提交出现之前main返回，那么可以快进返回，并且您不必生成新的合并提交（带有消息“将分支主合并到开发中”），如果你不想。如果您允许快进合并，那么之后将指向相同的提交，该提交将是带有消息“将分支开发合并到主”的合并提交。如果您选择用于该合并，那么您当然会创建一个新的合并提交。dev devdevdevmain--no-ffdev两个合并之间，要么是因为您使用--no-ff并强制了它。所以呢？如果您强制合并提交（例如默认的 Git Flow 建议），那么是的，您将拥有合并提交，这意味着dev和main永远不会相同，这完全没问题。现在让我们来解决一下您的其他一些问题：
这个问题告诉我正确的方法是首先将 main 合并到 dev 中，以确保 main 分支保持干净。这是实现 dev --> main 合并的最佳方式吗？
这取决于你。在 Git Flow 模型中，如果出现新的提交，main您通常会希望尽快合并main回，dev这样您就不会测试与要部署的内容不同的内容。（或者更糟糕的是，如果您从dev临时release分支进行部署，那么您不会删除生产中的修补程序更改，main因为它们还不在您的release分支中。）因此，实际上并不是您需要合并在合并到之前main进入。相反，如果出现修补程序，您应该不久后将它们合并到其中。然后将随时准备好融入。devdevmainmaindevdevmain
这是否受到 git fast-forwards 默认合并这一概念的影响？...当 dev 分支简单地领先于 main 的提交时...合并将自动成为快进合并？
是的。如果可能的话，快进合并是默认设置。
这种行为对于将 dev 合并到 main 来说是否有问题，合并时是否应该使用 -no-ff 标志？
这没有问题。是否应该强制合并提交取决于您。有一些优点和缺点。摘自我对另一个问题的回答：
合并（使用 --no-ff）强制合并提交，这很有用，因为每个 PR 都包含与该 PR 关联的提交列表，使您能够查看第一个父历史记录，其中显示了分支中的所有合并，并轻松比较它们。强制合并提交的另一个好处是，只需恢复合并提交即可轻松恢复整个 PR，而不是单独恢复原始 PR 中的每个提交。
请注意，GitLab 将“拉取请求”称为“合并请求”，因此您可以将上一段中看到的“PR”替换为“MR”。强制合并提交的唯一缺点是：如果您不关心刚才提到的任何优点，那么它会给结果图增加不必要的复杂性。
最后，你问：
在本地合并分支后，我将如何将合并推向上游？我是否应该在本地合并 dev 和 main，或者只是继续使用 gitlab Web 界面来实现此目的？
如果您没有启用分支保护，那也没有什么区别。dev如果您为您的分支（在 GitLab 中）打开分支保护/策略main，那么您将需要使用合并请求功能来执行这些合并。完成合并请求后，您可以选择是要快进还是强制合并提交。如果您在本地执行此操作，那么您只需将分支推送到远程服务器（GitLab）（如果您有权限）。无论哪种方式，最终结果都是一样的。