我们经常从 master 分支出来处理大型功能分支。这些功能分支通常在与 master merge 之前工作数天甚至数周(尽管最佳实践表明我们需要尽可能频繁地 merge ，但实际上它可能会有所不同)。
因此，我们尽可能地尝试 git pull --rebase origin master 以便与 master 保持更新。然而，我们偶尔会遇到这样的情况，例如:
1) 从master分支分支到feature/new-branch
2) 在 feature/new-branch 中进行更改并提交更改。
3) git pull --rebase origin master 将提交置于 master 之上。修复所有冲突和 git add . + git rebase --continue
4) 在 feature/new-branch 中进行更多更改并提交更改。
5) git pull --rebase origin master 再次。
但是，在步骤 5)，该过程要求我们修复步骤 3) 中的相同冲突。这可能很乏味。
这是正确的最佳实践 git flow 吗？如果不是，我们还能做些什么来提高流程的效率？
最佳答案
如果您发现自己修复了相同的冲突，请尝试激活 git rerere (“重新使用记录记录的重新解决方案”)。
git config --global rerere.enabled true
那会为你记录那些冲突的解决。
在 Fix conflicts only once with git rerere 的“Christophe Porteneuve”中查看更多信息
if you prefer rerere to auto-stage files it solved (I do), you can ask it to: you just need to tweak your configuration like so:
git config --global rerere.autoupdate true
关于git pull --rebase origin master 似乎每次都从头开始 rebase ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37246151/