问GIT不会强制很多大的合并吗？

EN

真的，在git中几乎所有的情况下都有一种绕过合并的方法。不是合并，而是重新设置本地存储库的基址，重新安排历史。通过使用rebase，规范/源存储库永远不会重新排列，并且很少有任何合并提交，但本地存储库历史记录会重新排列，以便与主存储库更紧密地匹配。

所以：

git fetch
git rebase origin/master
// resolve any conflicts (if there are any) by altering your own commits
git rebase --continue
git push

并且所有的提交都是原子的，并且源/主节点永远不会有任何合并提交。

现在，在极少数的情况下，重新建立基础的过程将变得复杂，你会发现自己解决了很多冲突，在这种情况下，你可能想要git rebase --abort并退出重新建立基础的过程，然后进行合并，但我已经几个月没有需要在这一点上求助于合并了，所以保持历史线性并不是太难。

本质上，这是在采取破坏性最小的方法。你会说“嘿，我所有的提交都是我添加到本地主分支的--其他人放在中央分支/规范分支都是我的责任，所以-我-将会重新安排我的代码。”以这种方式，进入任何存储库的主分支的任何内容都首先被认为是规范的，其他人不必处理成功推送到主分支的任何内容的重写历史的合并提交。

是的，你可能会发现自己处于这种情况，但这是可以避免的。即使你决定只在几次(N次)提交后才决定push你的存储库，你仍然可以不断地从其他分支，这样你就可以总是与其他人正在做的事情集成。无论如何，Git在合并方面都做得很好。

不用谢。git中的每个提交都是唯一可识别的，无论它位于哪个repo中。因此，合并完全按照它们应该的方式工作。Git对冲突解决也有非常好的支持，这使得它在合并方面甚至比其他一些VCS更好。