git pull --rebase花了太长时间，我有什么替代方案？
在我们的组织中，我们拥有一个巨大的回购，其中许多开发人员每天都在做。
我想在提出拉取请求之前将代码重新设置为最新版本 我在主要回购后面做了大约3000次提交。 rebase花了大约4个小时（我没有任何合并冲突）。
我知道git clone会快得多。我有什么替代品，除了删除我的前叉并从主回购中新鲜分叉？
答案 0 :(得分：0)
注意：从Git 2.14.x / Git 2。5（2017年第3季度）开始，git pull --rebase的rebase部分将清楚地显示正在准备的补丁数量以及进度指示器。
commit 9eaa858见commit 738e88a，Kevin Willford (``)（2017年8月10日）
（由Junio C Hamano -- gitster --合并于commit ad7d3c3，2017年8月23日）
format-patch：生成补丁时有进度选项为rebase命令生成补丁时，如果用户执行了补丁 没有意识到他们正在改变的分支是成千上万的 提交不同，初始后没有进度指示 倒带信息。
此补丁中提供的进度表假设有数千个 修补程序具有精细的粒度以及假设需要全部 每个工作/时间相同，这样一个稳定的进度条 已经实现了。
此补丁允许将进度选项传递给format-patch 这样可以告知用户生成的进度 补丁。
所以下次，你马上就会知道这个变种需要时间。
另请注意，如果通过msys2在Windows上完成操作，则需要花费更多时间。
另一种方法是创建一个tmp分支，然后将当前分支重置为origin远程跟踪分支，最后将tmp合并到重置的分支：大规模合并是比申请数千个补丁更快。
答案 1 :(得分：0)
当我发布问题时，我不知道'git merge'。或者更确切地说，我习惯于'git rebase'而不是习惯'git merge'。
'git rebase'所做的是将所有提交删除，直到找到一个公共父级，然后首先应用上游更改（您正在合并的分支），然后应用您在当前分支中的更改。这个过程需要很长时间。修复冲突后，每次都必须修复冲突。
现在，只要有大的合并，我就会使用git merge。它比rebase更好，更快。