这是参考git-commit-history-lost中提出的问题，提出的建议帮助我解决了其中一个提交不在本地但在位存储桶中出现的提交的问题
我遵循了建议，并能够通过本地提交缺少提交信息的提交历史记录。
我想问一下在本地运行命令git log时没有出现提交的情况是什么？
也将有兴趣知道此命令git log --follow -p -- <file name>在执行什么操作。
我们将来如何避免此类问题，以便我们可以通过运行git log
答案 0 :(得分：1)
如果要查看远程日志，则第一个本地需要具有远程索引的副本。
进行git fetch，这将有助于git了解相对于远程而言需要在本地更新的内容。
现在执行git log --all这将显示所有分支上的所有日志。
注意：：如果您没有执行git fetch，则本地计算机将不知道远程分支中的更新内容。
git log仅显示当前的本地分支更新。
git log不检查远程存储库中的内容。
但是git log --all显示所有分支的提交历史记录。
要了解什么是本地分支机构和远程分支机构，git bash会将所有green着色为本地分支和red着色为远程分支，因此可能会更改为其他bash终端。
答案 1 :(得分：0)
手册页（或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哪个是重命名文件，哪个是新文件。
无论如何，面对这种情况，您可以明确要求监视这些更改，并在可能的情况下自动跟踪文件状态，以进行历史记录浏览。但是，如文档中所述，因此它一次只能跟踪一个文件。