这是关于git-commit-history-lost提出的一个问题，所提出的建议帮助我解决了其中一个提交没有出现在本地但是在bitbucket中的问题，该提交正在出现
我遵循了这个建议，并能够在本地删除提交历史记录中缺少的提交信息。
我想问一下在本地运行命令git log时发生了什么事情没有出现？
也有兴趣知道这个命令git log --follow -p -- <file name>is执行什么。
我们如何在将来避免此类问题，以便通过运行git log来获取每个提交历史记录
如果要查看远程日志，首先需要拥有远程索引的副本。做一个git fetch这将有助于git了解需要在本地更新遥控器。
现在做一个git log --all这显示所有分支上的所有日志。
注意：如果您没有执行git fetch，则本地计算机将无法知道远程分支中的更新内容。
git log仅显示当前的本地分支更新。
git log不检查，远程存储库上有什么。
但git log --all显示所有分支机构提交历史记录。
要了解什么是本地和远程分支git bash区分所有green着色为本地分支和red着色为远程分支，它可能会改变其他bash终端。
手册页（或git文档）是你的朋友：
--follow
Continue listing the history of a file beyond renames (works only for a single file).
-p, -u, --patch
Generate patch (see section on generating patches).
所以最有可能的情况是，如果你确定提交是在你正在浏览的分支上并且它不在下游，那么就是在你开始浏览分支之后的位置（如果你处于分离状态会发生这种情况）模式，在给定时间检出特定提交），您的文件曾被重命名，或以后删除/重新创建。
Git使用“快照”，这意味着每次提交时，git实际上存储工作目录的完整状态，独立于每个其他提交，甚至是父提交。它通过将完整的文件列表存储到树对象中来实现，树对象又指向包含文件内容的对象（如果它们不更改，这些对象在每次提交时都会发生相同，因此不会存储重复数据，这意味着不会浪费空间）。
这使得Git在比较事物时非常有效，使得两个随机提交的区分非常简单，即使它们完全不相关。事实上，git只是不必记住事件的历史。每个提交引用其自己的父级，就像链接列表一样，实现了分支。
这样做的缺点是单个给定文件的两个版本之间的相关性基于其文件名。如果此文件名发生更改，则会破坏其自身历史记录的谱系。
幸运的是，git意识到了这一点，并提供了许多启发式方法，让它可以回归到它的脚。例如，如果它在一次提交中检测到文件删除和产生具有完全相同内容的新文件，则git将假定它是文件重命名，即使用户实际上已经真正删除然后重新创建文件。无论如何，无论git还是严格的文件系统观点，这两个操作都完全等效（我们不关心inode等）。
如果您使用常规shell命令执行此操作，Git将能够处理此问题，但为此使用git特定命令始终是个好主意，例如：
git mv <oldfilename> <newfilename>
...因为如果它认为在这个操作中会丢失一些线索，它就有机会提供额外的信息。否则，所有这些仍然有限。假设您已经删除了一个文件，然后重新创建了两个具有相同内容的其他文件，然后没有任何内容告诉Git哪个是重命名的文件，哪个是新文件。
无论如何，当遇到这种情况时，您可以明确要求监视这些更改并自动跟踪文件状态（如果可以），继续进行历史记录浏览。但正如文档中所述，它一次只能跟踪一个文件。