Git 每次提交后推比多次提交后推有什么好处和成本

我养成了在每次提交后推送到

原点的习惯。我的大多数提交都是相当琐碎的，从这个意义上说，我是在做了一些小的更改之后才提交的。这是一种好的做法吗

我的印象是，与多次提交后的推送相比，每次小提交后的推送都会增加存储库的大小。这种理解是错误的吗？
在团队中工作时，频繁的推送会让你个人的生活更轻松，因为最后推送的人需要解决合并冲突。在这方面，不太频繁推送的其他人可以通过更频繁地拉送使他们的生活更轻松，以便在他们的存储库偏离太远之前检测到冲突

频繁推送的缺点是，推送提交后，无法使用rebase对提交进行重新排序或挤压，也无法再对其进行加载。这可能是一件个人的事情，但是当我有一个小的改变，它符合上一个提交的描述时，我宁愿修改上一个，而不是创建一个新的。在你推了之后，你不能再这样做了。因此，当您频繁地推送时，您将得到更多琐碎的提交，这会使git日志变得不必要。
只要您的提交只驻留在本地存储库中，您就可以对其进行处理（
git提交--amend
修复上次提交，或者
git rebase-i
重新排序和整理您的工作）。在提交后立即推送它们会使以后很难修复

我喜欢每天推送一次我的更改，除非它们即将由其他人部署或测试。这给了我一个机会，让我发现我做了一些事情有点太早了

它不应该以任何方式影响存储库的大小

我养成了一种习惯，每次犯下错误后都会追根究底。
从我的承诺的意义上说，我的大多数承诺都是微不足道的
在做了一些小的改变之后。这是一种好的做法吗

在我看来，你不应该把每一个承诺都推到原点。相反，在处理完某个功能后使用交互式重定基来挤压较小的提交，并将该功能作为一个提交推送到原点。但这个问题并没有明确的答案——谷歌搜索“git工作流”会给你几个选择

我的印象是，在每一个小小的承诺之后，我都会努力
与制作后推送相比，增加了存储库的大小
几项承诺。这种理解是错误的吗

错。但是，如果在推送之前重新设置基址，那么压缩的提交将不会在源位置结束。
我建议您阅读以下内容：另外，您应该有一个独立于Git的良好工作区备份过程-您不应该只为备份而推送，而是在您觉得您的工作适合分发给其他人时推送。