我们经常从master分支到大型功能分支。这些功能分支通常在与master合并之前工作数天甚至数周（尽管最佳实践要求我们需要尽可能频繁地合并，实际上它可能会有所不同）。
因此，我们尽可能地尝试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流程，如果没有，我们还能做些什么来提高流程效率？
答案 0 :(得分：2)
如果您发现自己正在修复相同的冲突，请尝试激活git rerere（“重新使用重新有线重新解决方案” ）。
git config --global rerere.enabled true
那将为你记录那些冲突解决方案。
点击Fix conflicts only once with git rerere
中的“Christophe Porteneuve”了解详情如果您更喜欢rerere自动暂存它已解决的文件（我这样做），您可以问它：您只需调整配置如下：
git config --global rerere.autoupdate true
答案 1 :(得分：1)
您还可以git merge主分支进入您的功能分支，以便继续获取最新更改并简化向主数据库的过渡。
对于一个长期运行的分支（你不应该这样做，但是嘿，现实并不完美：D）我通常更喜欢这个选项来避免重写--rebase所做的整个分支历史。