每次执行git pull --rebase origin master命令似乎都会从头开始进行变基。

Question

我们经常从主分支(master)分支出来，开始在大的功能分支上工作。这些功能分支通常会被工作了几天甚至几周之后才与主分支合并(尽管最佳实践指导我们需要尽可能频繁地进行合并，但实际情况可能不同)。

因此，我们尽可能地使用"git pull --rebase origin master"命令来保持与主分支的同步。然而，在某些情况下，我们可能会遇到以下情况：

1. 从主分支(master)分支出来，创建一个名为"feature/new-branch"的新分支。 2. 在"feature/new-branch"中进行更改，并提交更改。 3. 运行"git pull --rebase origin master"命令，将提交放在主分支上面。修复任何冲突，并运行"git add ."和"git rebase --continue"命令。 4. 继续在"feature/new-branch"中进行更改，并提交更改。 5. 再次运行"git pull --rebase origin master"命令。

但是，在第5步中，我们需要解决与第3步相同的冲突。这可能会很麻烦。

这是否是正确的最佳实践git流程？如果不是，我们还可以做些什么来使过程更有效率？

- Wei Jia Chen

Answer 1

如果您发现自己一再解决相同的冲突，请尝试激活git rerere（“重复使用记录的解决方案”）。

git config --global rerere.enabled true

这将为您记录冲突解决。

详见《使用 Git rerere 解决冲突》，作者：Christophe Porteneuve

如果你喜欢让 rerere 自动暂存它已经解决的文件（我个人是这么做的），你可以按以下方式调整配置：

git config --global rerere.autoupdate true

- VonC

---

这是一个很好的建议！我下次rebase时一定会尝试一下。这似乎也是一个不错的参考资料 https://git-scm.com/docs/git-rerere。 - Wei Jia Chen

@WeiJiaChen 我同意：https://git-scm.com/docs/git-rerere 是我在 git rerere 下的答案中提到的第一个链接。 - VonC

明白了！是我疏忽了 :) 非常感谢 @VonC - Wei Jia Chen

Answer 2

你也可以将主分支合并到特性分支中，以保持最新更改并使过渡到主分支更容易。对于长期运行的分支（虽然不应该这样做，但现实并非完美:D），我通常更喜欢使用此选项，以避免重写整个分支历史，而 --rebase 会这样做。

- Hugo Ferreira