为什么git-rebase-to-a b，git-rebase-to-b-a会创建一个与原始版本不同的SHA1？

假设您有以下修订图，其中c是当前分支：

c   a
 \ /
  b

git-rebase——在b上创建以下内容：

    c
   /
  a
 /
b

和
git-rebase--to b a
将图形返回到：

c   a
 \ /
  b

然而，c的新SHA1不同于c的旧SHA1，在这两个重新调整之前。为什么会这样？
提交的SHA1取决于提交的所有内容，包括元数据。特别是，它取决于提交时间戳。您的两次重基提交有一个新的时间戳，因此它有一个新的SHA1

（请注意，最初编写时有一个“作者日期”，记录实际提交时有一个“提交人日期”。只有后一个日期发生了变化。要亲自查看这一点，请使用
git log--pretty=fuller
，或者只需查看
gitk
中的提交即可）
有趣。让我困惑的是，它没有改变SHA1，因为在执行重定基址的新基址上没有其他提交。我想如果你在新的基础上还有额外的工作，那就需要创建新的提交，因此需要一个新的时间戳。@jonderry：我相信rebase足够聪明，如果不需要的话，它不会做任何事情。我不会指出时间戳，而是指出历史。提交有一个包含在哈希中的父级。如果父级更改，则提交更改。如果父项没有改变，而提交的其他内容也没有改变，那么就不必做任何事情。@Dustin：再看看这个问题。提交已重设为其原始父级。啊，你说得对。我回答了一个没人问的问题。很抱歉给你带来了困惑。