git pull --rebase origin master似乎每次都会从一开始就重新设置基准

Question

我们经常从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 flow吗？如果不是，那么我们还能做些什么来使过程更高效？

Answer 1

如果你发现自己固定在同一冲突，试图激活git rerere （“ 再利用再 重新有线解决方案”）。

git config --global rerere.enabled true

它将为您记录那些冲突解决方案。

参见Christophe Porteneuve的 “ 使用git rerere仅解决冲突一次 ”中的更多内容

如果您喜欢rerere来自动暂存已解决的文件（我愿意），可以要求它：您只需要像这样调整配置：

git config --global rerere.autoupdate true

Answer 2

您也可以git merge master分支git merge到功能分支中，以保持获取最新更改并简化向master的过渡。

对于运行时间较长的分支（您不应该这样做，但是，现实并不完美：D），我通常更喜欢使用此选项以避免重写--rebase那样重写整个分支历史。