我正在开发一个项目，其中我们有以下分支：
我们创建功能分支的方式是将main分支分支为feature/<id>。然后我们稍后从feature/<id>到dev创建PR。如果一切正常等等，我们就会继续使用feature/<id>到test，然后到main。
问题在于，有时我们从feature/<id>到dev存在冲突。我们永远不想将dev合并到功能分支中（以避免将所有dev代码发送到测试）。因此，为了解决冲突，我们使用Azure界面（非常糟糕）来解决合并冲突。通过使用这个工具，它不会将dev合并到功能分支中，它正好做我们想要的事情，即feature -> dev（在保持PR打开的某个临时状态中）。
要在本地执行相同的操作，目前我们找到的唯一替代方法是从 dev 创建一个临时分支，将功能合并到此新分支中，并使用 temp 重新提交 PR- > dev。
在这种情况下，有更好的处理冲突的方法吗？
这是一个常见的问题，顺便提一下，你有3个分支并不重要；只需要2个分支就可以出现这个问题。如果你使用Git项目使用的工作流程，仅使用next和main就经常会发生这种情况。减少问题的方法是定期将next重置为main，或者在您的情况下，您可以考虑定期将dev和test都重置为main，以删除所有以前未进入main的旧代码。
在重置之间，我只能想到3个好的选择（其中2个已经被提到）：
到目前为止，我们找到的唯一替代方法是从dev创建一个临时分支，将功能合并到这个新分支中，并重新制作temp->dev的PR。
dev被重置。第二个烦恼是如果你在从特性分支合并到dev之后才注意到冲突，你必须放弃该PR并为临时分支创建一个新的PR，这导致了可能的第三个选项，但我只建议在你熟悉交互式变基的情况下使用：
dev合并到你的工作特性分支中以解决冲突。本质上，你会在本地将dev合并到你的分支中，但使用一种压缩方式，并将提交消息设置为"delete-me: Squash merge in dev"。请注意，你在这里污染了你的分支，但这样做可以更轻松地在你准备推广你的分支时删除合并。一旦你准备好推广，也就是在你的情况下是test，你将进行交互式变基并删除所有这些"delete-me"提交。
小提示：根据您的描述，我无法确定您是否将功能分支合并到了test，然后再将这些功能分支单独合并到main。如果是这样的话，那么在test上可能会出现相同的问题，您需要在进入main之前重复此过程。（另一种选择是当test准备好时，将其合并到main中，如果您这样做，就不应该有这个问题。如果您单独合并功能分支，那么您可能还想定期重置test。）
提示：不要使用常规合并将dev合并到您的功能分支中。要么维护两个分支，要么使用压缩合并。在晋升时，您不希望手动挑选分布在您的分支上的多个提交。
我的做法： 我过去常切换在 #2 和 #3 之间，但现在我主要以一种可能是选项 #4的方式进行：首先，我从 dev 分支开始，添加一些提交，合并到dev，再添加更多提交，再次合并到dev等等。在这个过程中，我不会重写我分支上的任何提交；我只会添加新的提交。如果我能在 dev 上完成这个过程而没有冲突，那么当我准备推进时，我会把自己的分支重写为几个我满意的好的提交，然后使用 --onto 将其变基到新的目标分支。如果在这个过程中我遇到了冲突，并且无法简单地向我的分支添加新的提交，那么这是我决定选择 #2 或 #3 的时候。