命令“gitstatus”列出比“gitlog”更多的提交

我在一個主題分支中做了一些作業，在完成作業之前進行了兩次中間提交。然后我回到 master 并合并了我的主題分支。我習慣與 合并--no-commit，所以我可以在提交之前檢查一切是否正常，但這是一個快進，我沒有用 --no-ff 阻止它。現在“git status”告訴我有 5 個提交要推送，但“git log”只顯示 3 個——我在主題分支上所做的提交數量：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 5 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
$ git log
commit f4474af2add220b1c2f0bf07d92f5035cef622ef (HEAD -> notifiche, master)
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Fri Dec 10 14:55:48 2021  0100

    [...]

commit b63a44f7c1266a53a0e5c91a3395fc9eb75d9bd2
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Tue Dec 7 16:46:59 2021  0100

    [...]

commit beb5d335e0ac35184b6a8e78bf45627e705a2a9b
Merge: 1f16a0d 025f660
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Tue Dec 7 16:46:18 2021  0100

    [...]

commit 025f660ebc22b2d3bee00c691657c6e7318fcf50 (origin/master, origin/HEAD)
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Tue Dec 7 11:44:48 2021  0100

    [...]

commit 1f16a0dcd96862b0ca75d3f3ca896ad755ccf29e
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Thu Nov 25 09:38:21 2021  0100

    [...]

這是正常的嗎？是否有一些我沒有看到的“隱藏”提交？

在您的回答中，請考慮我可能需要推送我的提交，但我想這不應該改變本地提交歷史，對嗎？

編輯：回復 Lasse V. Karlsen 問題：

$ git log --format="%h %d"
8059943  (HEAD -> master)
b63a44f
beb5d33
025f660  (origin/master, origin/HEAD)
1f16a0d
0bd94aa
1e9d375  (dizione_e_sede)
c19c33a
c2bc958
d1801c3
1dd9a87
e4f0846
2091d2e  (origin/conv_pdf)
84076f3
[...]
$ git log --format="%h %d" origin/master..master
8059943  (HEAD -> master)
b63a44f
beb5d33
1f16a0d
0bd94aa
$

在服務器上，我看到以下內容：

將滑鼠懸停在紅色圓圈 X 上時，會出現一條訊息“管道：失敗”。

我還應該提到，我們將 gitlab 服務器從一個非常舊的版本升級到 14.4.1，就在這些提交的中間——這可能是相關的嗎？...

uj5u.com熱心網友回復：

嘗試從 CLI（命令列）使用：

git log --oneline --decorate --graph --all

或者如果您有 GUI（在 Windows 或 Linux 或 Mac 上）：

gitk --all

這將使您能夠以更具視覺吸引力的方式查看歷史。我相信這就是你要找的。

uj5u.com熱心網友回復：

這是正常的。git status顯示您提前五次提交的命令是正確的（Git 中的模錯誤，這相對罕見）。git log您看到的輸出也是正確的，但包含一種微妙的謊言：

commit f4474af2add220b1c2f0bf07d92f5035cef622ef (HEAD -> notifiche, master)
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Fri Dec 10 14:55:48 2021  0100

    [...]

commit b63a44f7c1266a53a0e5c91a3395fc9eb75d9bd2
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Tue Dec 7 16:46:59 2021  0100

    [...]

commit beb5d335e0ac35184b6a8e78bf45627e705a2a9b
Merge: 1f16a0d 025f660

當git log顯示提交時，它使用使用優先級佇列的相當復雜的內部演算法來實作。這處理了提交圖是 DAG 而不是簡單樹的事實。特別是合并提交會導致棘手的遍歷。

請注意，此處串列中的第三個提交實際上是一個合并提交，有兩個父項：（1f16a0d縮短）和025f660（也縮短）。

以線性化順序顯示的下一個提交git log是：

commit 025f660ebc22b2d3bee00c691657c6e7318fcf50 (origin/master, origin/HEAD)
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Tue Dec 7 11:44:48 2021  0100

或025f660：這是合并的第二個父級。這是origin/master命名的提交。

之后git log顯示的提交是： 025f660

commit 1f16a0dcd96862b0ca75d3f3ca896ad755ccf29e
Author: Francesco Marchetti-Stasi <f.marchettistasi@***>
Date:   Thu Nov 25 09:38:21 2021  0100

這是該合并的第一個父級。它顯示在之后而不是之前的原因是它的時間戳（11 月下旬）早于025f660（同年 12 月 7 日）的時間戳。

至少在我看來，如果我們畫個圖，這一切就更清楚了。這里就是你看到的，我在那里已經取代每次提交一個簡單的大丑散列ID的區域圖形o或*或●：

...--●--o--o---*--o--o   <-- master
      \       /
       ●-----●   <-- origin/master

標記的提交*是合并提交。哈希 ID 已被黑色圓圈替換的提交●在兩個分支上；其他提交僅在master. 有四個開放的圓圈和一個帶星號的合并，所以有五個提交master不在origin/master.

可以通過多種方式繪制此圖：¹使用git log --graph, 或git log --graph --oneline，將使 Git 為您繪制一張，垂直方向，最新提交位于頂部。因為git log輸出一次提交一個，任何不提交的序列包括圖表，但確實包括合并提交，當它暗示一個簡單的線性提交鏈時，一定是某種謊言（遺漏或傭金，取決于您喜歡什么以及您如何看待它）。那是因為合并提交將一些原本分開但并行的鏈聯系在一起。log 命令必須遍歷鏈的兩側，或省略鏈的一側，無論您告訴它做出何種選擇，結果要么是不完整的（“只遍歷第一父鏈接”）要么不正確 - 或 -根據您的觀點不完整。

¹這是另一種繪圖，我認為，在大多數情況下，它使情況更加清晰，盡管git log --graph根本不會繪制這樣的東西：

       o--o
      /    \
...--●      *--o--o   <-- master
      \    /
       ●--●   <-- origin/master

這就是我喜歡布置我的圖紙的方式，以展示我的git merge作業原理。

Optional reading: some further details

The git log algorithm uses a priority queue.

The code begins by seeding the queue with one or more starting point commits (if there are no starting point commits, git log does nothing, but the default is to use the HEAD commit, and HEAD almost always specifies a commit: the exception is when you are on a branch that does not exist, which Git calls an orphan branch or an unborn branch—Git is not consistent about which term it uses). That is:

git log

inserts the HEAD commit (only) into the queue, while:

git log --branches

inserts all branch-tip commits into the queue, and:

git log master origin/master

inserts the commits identified by the names master and origin/master (this may be one single commit, if both names select the same commit, or two separate commits as in your case).

Because the queue is a priority queue, if it contains more than one entry, the "front" entry is the one with the highest priority. This is controlled by various options to git log, such as --date-order, --author-date-order, or --topo-order, but the default is to use the committer timestamp (which is not shown by default: the dates you see here are author dates; but fortunately most commits have the same author and committer date), with the latest timestamp—the most recent commit—having the highest priority.

If the queue has only one entry, of course, that one entry has the only priority, which is therefore the highest, average, and lowest priority all at the same time. So that's a degenerate case—but an important one since very often, there's only one entry in the queue. For instance, that's the case for your git log, which inserts just the HEAD commit, which is also the master commit.

The log code now runs a loop:

• while the queue is not empty
  • remove the front entry (a commit)
  • decide whether to show this commit
    • if so, show it (there's a special bit of weirdness with --reverse here though)
  • decide which parent(s) if any to insert into the queue

The defaults for the two "decide" steps are: yes, do show it; insert all parents.

大多數提交只有一個父提交，因此對于第一個提交——由HEAD和和notifiche和標識master——回圈顯示一個提交，用兩個分支名稱“裝飾”，并插入它的一個父提交b63a44f7c1266a53a0e5c91a3395fc9eb75d9bd2。

佇列現在有一個提交，所以回圈運行并顯示第二個提交。那個提交沒有名字——沒有分支識別符號，沒有標簽等等——所以我們只看到那個提交，沒有(origin/master)或任何東西。父級也有一個父級，因此一個父級進入佇列：我們現在在beb5d335e0ac35184b6a8e78bf45627e705a2a9b，這是合并提交。

佇列現在有一個提交，所以回圈運行并顯示第三個提交。這個提交有兩個父級，1f16a0d和025f660. 它們都被插入到優先佇列中。

現在我們點擊優先級代碼：佇列有兩個條目。其中之一在前面。在git log代碼中抽取一個。它是第二個父級，但它具有更高的優先級，因為它具有較晚的提交者時間戳。

在git log現在的代碼顯示了這個承諾，這被稱為一個名字，origin/master所以現在你看到的誤導性輸出。該提交有一個父項，它進入佇列，佇列中繼續有兩個元素。

這種模式一直重復，直到通過合并向后隱含的分支本身得到解決。一旦有只有一個承諾是在佇列中，我們回到正常的單執行緒的步行路程。（使用--topo-order確保盡快發生這種情況，并--graph暗示--topo-order.）

標籤：混帐

上一篇：是否可以將Gitlab版本遷移到Github存盤庫？

下一篇：如何手動指定gitcommitsha？