当我的设备日期时间设置为未来几天（即日期设置为 23 日而不是 21 日）时，我不小心提交并推送了一项更改。
我已经推荐了this，这将解决我的问题，但由于强制推送，建议不要执行。
所以我的问题是保持错误的提交日期和时间会对 Git 存储库（本地和远程）产生不利影响。我使用“Git Lab”作为我的远程存储库提供程序。
【问题讨论】：
parent 提交引用。也就是说，git 是围绕按时间顺序重新排序的提交设计的——这就是你 rebase 的方式。
rebase 就不是问题
rebase 是一个非常常见的操作。
但由于强制推送，建议不要执行。
任何变基都需要强制推动变基分支的发布。
但这只是一个问题，这是在多个合作者正在工作的公共分支上完成的。
如果它是您自己的工作/主题分支，您可以根据需要多次变基/强制推送。
这实际上是在before a pull request 完成的，以确保维护者轻松合并（或者维护者可以trigger the rebase themselves）。
【讨论】：
所以我的问题是会保留错误的提交日期和时间 对 Git 存储库（本地和远程）产生不利影响。我使用“Git Lab”作为我的 远程存储库提供程序。
答案是：“视情况而定”。从 git 的角度来看，它没有：日期被记录为元数据，提交顺序是基于父/子关系提供的。进一步研究请参阅this answer。
但是，如果您 employ CI scripts 或非常关心存储库的实际历史记录，那么从广义上讲，记录错误的元数据不好。可以修。
顺便说一句，您可以使用元数据做很多事情，例如但不限于creating commits in the past。
提交
Git 提交对象的最终创建通常由 git-commit-tree 完成，它使用这些环境变量作为它的 主要信息来源，回退到配置值 仅当这些不存在时。
GIT_AUTHOR_NAME是“作者”字段中的人类可读名称。
GIT_AUTHOR_EMAIL是“作者”字段的电子邮件。
GIT_AUTHOR_DATE是用于“作者”字段的时间戳。
GIT_COMMITTER_NAME设置“提交者”字段的人名。
GIT_COMMITTER_EMAIL是“提交者”字段的电子邮件地址。
GIT_COMMITTER_DATE用于“提交者”中的时间戳 字段。
user.email未设置配置值。如果没有设置，Git 会退回到 系统用户名和主机名。 source
这是了解 git 内部结构的另一个非常好的参考：
让我们稍微考虑一下这些对象的哈希值。假设我 编写了字符串
git is awesome!并从中创建了一个 blob。你做了 在您的系统上也是如此。我们会有相同的哈希吗？答案是 — 是的。由于 blob 包含相同的数据，它们将 具有相同的 SHA-1 值。
如果我创建了一棵引用
git is awesome!的 blob 的树，并且 给它一个特定的名称和元数据，你在 你的系统。我们会有相同的哈希吗？再次，是的。由于树对象是相同的，它们将具有 相同的哈希。
如果我使用提交消息
Hello创建了该树的提交，该怎么办？ 你在你的系统上做了同样的事情。我们会有相同的哈希吗？在这种情况下，答案是 — 否。即使我们的提交对象引用 到同一棵树，他们有不同的提交细节 — 时间，提交者 等等。 source
【讨论】：