为什么推送 4 个文件的提交显示 "Writing hundreds of objects..."？
Why the push of a commit about 4 files is showing "Writing hundreds of objects..."?
我迷失了 git。我提交了 4 个文件。我在 Github 上的存储库有大约 60 个文件。
我想将这 4 个文件推送到我的远程存储库。
但是当我推送此提交时，我在进度日志中看到该命令正在写入数百个对象。这让我很担心。我害怕覆盖我远程存储库中的一些重要文件。
这是我在终端上看到的：
E:\Dropbox\cff\Python\Projet_Compilation\Projet_debug3>git push origin 1effeafeaeed20a44a8acffcfd575e39da314f26:main
Enumerating objects: 277, done.
Counting objects: 100% (158/158), done.
Delta compression using up to 6 threads
Compressing objects: 100% (103/103), done.
Writing objects: 14% (15/103)
所以我搜索命令以了解我的提交中有哪些文件：
E:\Dropbox\cff\Python\Projet_Compilation\Projet_debug3>git diff-tree --no-commit-id --name-only -r dca7f4f
modules/robots/platform/Smartphone_platform_1.py
modules/robots/platform/Smartphone_platform_2.py
modules/robots/platform/Smartphone_platform_3.py
modules/robots/platform/Smartphone_platform_4.py
这个命令向我确认只有 4 个文件将写入远程存储库。
那么为什么控制台的命令日志会显示上百个对象的写入呢？
当我使用 PyCHarm 执行此操作时，我什至可以看到这些对象的总大小是几个 Mega Octets。我的 4 个文件是简单的 Python 脚本，可能代表几个 Ko，仅此而已。
我真的很困惑。谁能给我解释一下？
Git 打印的对象计数对人类不是特别有用。他们并没有完全使用less，他们只是没有明确和直接对应大多数人真正想知道的东西。
在你的情况下，你想知道的——虽然你不知道你想知道这个——就是为什么 git push 发送了一些非常大的提交和非常大的文件，答案是 git push 通过 commits 工作，而不是文件。 Git 本身通过提交而不是文件工作。
提交已编号。这些数字是 random-looking，hexadecimal 中表示的巨大而丑陋的东西，对人类几乎没有用。但是这些数字是 Git 找到 提交的方式。出于人类目的，我们将数字隐藏在名称后面，例如分支名称。分支名称 与提交本身无关： 这只是我们 Git 软件为我们记住哈希 ID 的一种方式。
最终，每个 Git 提交是由两部分组成的——或者无论如何代表，你不妨认为它是——由两部分组成：
每个提交都包含一个每个文件的完整快照，就像你（或任何人）告诉Git时它的形式一样快照所有文件。这里有很多注意事项和“但是”，但每次提交都等同于 tar、rar、WinZip 或每个文件的其他存档。
而且，每个提交都包含一些元数据，或者关于提交本身的信息。这包括诸如提交人的姓名和电子邮件地址之类的信息——在这种情况下，您的姓名和电子邮件地址取自您的 user.name 和 user.email 设置。1这里还有很多内容，例如一些日期和时间戳，以及使 Git 实际工作的提交部分，但我们不会在这里介绍它们。
每次提交的所有部分 完全 read-only。一旦做出，就不能更改任何提交。如果你做了一个“坏的”提交，你必须将它从分支的末尾弹出。只有 end-of-branch 提交可以像这样被弹出，所以要弹出一个 还没有结束 的错误提交，你必须弹出多个提交，一直回到错误一.
之后，您可以tart 进行“良好”提交（包含您希望 包含的文件，and/or 元数据你想要，全部代替坏的）。 new-and-improved 替换提交与原始提交有 不同的数字 。但是，由于我们（人类）从未真正查看数字，而是选择查看分支名称，因此我们从未 注意到发生了这种情况 因为我们 Git 引用了我们的 new-and-improved 现在通过名称提交。
当您 运行 git push 时，您的 Git 会调用其他一些 Git 软件（甚至可能不是 Git：它可能是，例如，libgit2 或 jgit 或 Go-Git 或其他东西，只要它“说 Git”）。该其他软件可与某些 其他存储库 配合使用。另一个存储库有 its 分支名称。但是您的存储库和他们的存储库将 共享提交 。他们通过提交编号（而不是分支名称）来执行此操作。您的 Git 列出了他们尚未提交的任何新提交，然后您的 Git 将 发送 这些提交——连同他们的内部支持对象——你会看到那些：
Counting objects: ... done
此时有消息。他们的 Git 软件现在可以在接受或拒绝您的 Git 更新他们的 他们的 之一的请求之前检查提交的善意或他们关心的任何内容分支名称以记住最新的提交（除了或代替旧的最后一次提交之前记住的名称）。
如果他们不喜欢你的提交，你可能不得不从分支的末尾弹出一些并构建他们喜欢的新分支.如果这涉及从一些早期提交中删除一些大文件——这些删除也会传播到后来的提交中——那很好。还有一些工具可以做到这一点；参见，例如 How to remove/delete a large file from commit history in the Git repository?
1请注意，这是 Git 使用 这些设置的唯一地方。当您向某个网站验证推送或获取操作时，Git 不会自行进行验证：它会将验证交给其他程序或库。彼此 program-or-library 有 自己的 身份验证方法，根据设计，这些方法不涉及查看 user.name.
我迷失了 git。我提交了 4 个文件。我在 Github 上的存储库有大约 60 个文件。 我想将这 4 个文件推送到我的远程存储库。
但是当我推送此提交时，我在进度日志中看到该命令正在写入数百个对象。这让我很担心。我害怕覆盖我远程存储库中的一些重要文件。
这是我在终端上看到的：
E:\Dropbox\cff\Python\Projet_Compilation\Projet_debug3>git push origin 1effeafeaeed20a44a8acffcfd575e39da314f26:main
Enumerating objects: 277, done.
Counting objects: 100% (158/158), done.
Delta compression using up to 6 threads
Compressing objects: 100% (103/103), done.
Writing objects: 14% (15/103)
所以我搜索命令以了解我的提交中有哪些文件：
E:\Dropbox\cff\Python\Projet_Compilation\Projet_debug3>git diff-tree --no-commit-id --name-only -r dca7f4f
modules/robots/platform/Smartphone_platform_1.py
modules/robots/platform/Smartphone_platform_2.py
modules/robots/platform/Smartphone_platform_3.py
modules/robots/platform/Smartphone_platform_4.py
这个命令向我确认只有 4 个文件将写入远程存储库。
那么为什么控制台的命令日志会显示上百个对象的写入呢？ 当我使用 PyCHarm 执行此操作时，我什至可以看到这些对象的总大小是几个 Mega Octets。我的 4 个文件是简单的 Python 脚本，可能代表几个 Ko，仅此而已。
我真的很困惑。谁能给我解释一下？
Git 打印的对象计数对人类不是特别有用。他们并没有完全使用less，他们只是没有明确和直接对应大多数人真正想知道的东西。
在你的情况下，你想知道的——虽然你不知道你想知道这个——就是为什么 git push 发送了一些非常大的提交和非常大的文件，答案是 git push 通过 commits 工作，而不是文件。 Git 本身通过提交而不是文件工作。
提交已编号。这些数字是 random-looking，hexadecimal 中表示的巨大而丑陋的东西，对人类几乎没有用。但是这些数字是 Git 找到 提交的方式。出于人类目的，我们将数字隐藏在名称后面，例如分支名称。分支名称 与提交本身无关： 这只是我们 Git 软件为我们记住哈希 ID 的一种方式。
最终，每个 Git 提交是由两部分组成的——或者无论如何代表，你不妨认为它是——由两部分组成：
每个提交都包含一个每个文件的完整快照，就像你（或任何人）告诉Git时它的形式一样快照所有文件。这里有很多注意事项和“但是”，但每次提交都等同于 tar、rar、WinZip 或每个文件的其他存档。
而且，每个提交都包含一些元数据，或者关于提交本身的信息。这包括诸如提交人的姓名和电子邮件地址之类的信息——在这种情况下，您的姓名和电子邮件地址取自您的
user.name和user.email设置。1这里还有很多内容，例如一些日期和时间戳，以及使 Git 实际工作的提交部分，但我们不会在这里介绍它们。
每次提交的所有部分 完全 read-only。一旦做出，就不能更改任何提交。如果你做了一个“坏的”提交，你必须将它从分支的末尾弹出。只有 end-of-branch 提交可以像这样被弹出，所以要弹出一个 还没有结束 的错误提交，你必须弹出多个提交，一直回到错误一.
之后，您可以tart 进行“良好”提交（包含您希望 包含的文件，and/or 元数据你想要，全部代替坏的）。 new-and-improved 替换提交与原始提交有 不同的数字 。但是，由于我们（人类）从未真正查看数字，而是选择查看分支名称，因此我们从未 注意到发生了这种情况 因为我们 Git 引用了我们的 new-and-improved 现在通过名称提交。
当您 运行 git push 时，您的 Git 会调用其他一些 Git 软件（甚至可能不是 Git：它可能是，例如，libgit2 或 jgit 或 Go-Git 或其他东西，只要它“说 Git”）。该其他软件可与某些 其他存储库 配合使用。另一个存储库有 its 分支名称。但是您的存储库和他们的存储库将 共享提交 。他们通过提交编号（而不是分支名称）来执行此操作。您的 Git 列出了他们尚未提交的任何新提交，然后您的 Git 将 发送 这些提交——连同他们的内部支持对象——你会看到那些：
Counting objects: ... done
此时有消息。他们的 Git 软件现在可以在接受或拒绝您的 Git 更新他们的 他们的 之一的请求之前检查提交的善意或他们关心的任何内容分支名称以记住最新的提交（除了或代替旧的最后一次提交之前记住的名称）。
如果他们不喜欢你的提交，你可能不得不从分支的末尾弹出一些并构建他们喜欢的新分支.如果这涉及从一些早期提交中删除一些大文件——这些删除也会传播到后来的提交中——那很好。还有一些工具可以做到这一点；参见，例如 How to remove/delete a large file from commit history in the Git repository?
1请注意，这是 Git 使用 这些设置的唯一地方。当您向某个网站验证推送或获取操作时，Git 不会自行进行验证：它会将验证交给其他程序或库。彼此 program-or-library 有 自己的 身份验证方法，根据设计，这些方法不涉及查看 user.name.