我的功能分支已超过30或更多提交。与此同时，在开发分支中，其他开发人员也没有推出其他功能。因此，每次在开发时发布新功能时，我都会被要求：
问题
第二步是这里的鸡脖子。在重新定位时，它给了我冲突 一切 提交该分支。这实际上是迭代和冗余的。注意，我不能总是立即修改开发分支，因为我在分支中的工作仍在进行中。
我尝试了什么？
squash 并尽可能地减少我的提交（但这有助于最少，因为大多数时候没有什么可以压扁）stash 我正在进行改变，并重新开发然后解除我的变化。 （但在这里，我也会遇到冲突）-preserve-merges 与rebase。 （但是这里的每个人都喊道，完全使用它 灰心）那么，当功能分支本身有很多提交时，处理功能分支上的变形开发到最少冲突的最佳方法是什么。我是一个更新鲜的人，所以回复一个有用的解释（或链接）将有助于继续。
工作流程是健全的（rebase）。
但冲突不应该一次又一次地解决。
为此，你有 git rerere：激活它（git config --global rerere.enabled true），最后一次解决冲突（或做一个 手动重新培训， 要么 使用 contrib/rerere-train.sh），你的下一个rebase将在你的下一个rebase重新使用这些冲突解决方案。
工作流程是健全的（rebase）。
但冲突不应该一次又一次地解决。
为此，你有 git rerere：激活它（git config --global rerere.enabled true），最后一次解决冲突（或做一个 手动重新培训， 要么 使用 contrib/rerere-train.sh），你的下一个rebase将在你的下一个rebase重新使用这些冲突解决方案。
我建议 保持你的功能小 （一两天），你的功能分支也会很小。 另一种方法是，不是每次将某些东西推到开发分支时，而是仅在有时，或仅在合并之前一次。 同样，您需要保持较小的功能，否则您将同时拥有太多冲突。
关于您的问题，您不能最小化rebase中的冲突数量。如果存在冲突，则无法避免。
但git有一种方法可以帮助你：我建议你启用 rerere 这代表 重用录制的分辨率。有了这个，git会记录您如何解决冲突，并在下次出现冲突时重新应用解决方案，以便您找到已解决的冲突。这样可以加快您的工作流程。
您可以使用全局启用rerere
git config --global rerere.enabled true
尝试 git merge 在执行之前从开发分支进入功能分支 git rebase。它会提供更多信息。