通過運行“ git log”不顯示提交歷史記錄

Question

這是參考git-commit-history-lost中提出的一個問題，提出的建議幫助我解決了一個提交不在本地但在bitbucket中出現的問題

我遵循了建議，並且能夠通過本地提交缺少提交信息的提交歷史記錄。

我想問在本地運行git log命令時未出現提交的情況是什么？

也有興趣知道此命令git log --follow -p -- <file name>在執行什么。

將來如何避免此類問題，以便我們可以通過運行git log獲得每個提交歷史git log

Answer 1

如果要查看遠程日志，則第一個本地需要具有遠程索引的副本。 進行git fetch可以幫助git了解需要在本地相對於遠程進行更新的內容。

現在執行git log --all這將顯示所有分支上的所有日志。

注意：如果不執行git fetch本地計算機將不知道遠程分支中已更新的內容。

git log僅顯示當前的本地分支更新。

git log不檢查遠程存儲庫中的內容。

但是git log --all顯示所有分支的提交歷史記錄。

要了解什么是本地分支和遠程分支， git bash會將所有green （本地分支）和red （遠程分支）區分開，對於其他bash終端，可能會更改。

Answer 2

手冊頁（或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哪個是重命名文件，哪個是新文件。

無論如何，面對這種情況，您可以明確要求監視這些更改，並在可能的情況下自動跟蹤文件狀態，以進行歷史記錄瀏覽。 但是，如文檔中所述，因此它一次只能跟蹤一個文件。