背景關系：我試圖擁有一個“干凈”的主分支，所以我使用了選項git merge --squash和git rebase -i HEAD~x，但是對于這兩個我都遇到了問題（主要是因為我不太了解 git）：
是）我有的 ：
C - D - E
/ \
A - B - - - - - F
我想看到一個“干凈”的日志歷史：
A - B - F
我終于發現我可以操縱日志輸出而不是更改歷史記錄，我認為這很棒：
使用git log --first-parent master給了我（簡化）：
F "merged commit"
B "second commit"
A "first commit"
但是有些東西我不明白：如果我更改了Fwith的提交訊息git commit amend -m "third commit"，我仍然會得到：
F "merged commit"
B "second commit"
A "first commit"
即使git log --graph輸出：
* F "third commit"
|\
| |
| * E "feature third commit"
| |
| * D "feature second commit"
| |
| * C "feature first commit"
| |
|/
* B "second commit"
|
|
* A "first commit"
那么，為什么不git log --first-parent master向我顯示修改后的訊息？
uj5u.com熱心網友回復：
該git commit --amend選項不會更改提交。它進行了新的和不同的提交。當 Git 執行此操作時，它會更新一個分支名稱，特別是當前分支名稱。
假設原始的提交順序是這樣的。注意：我傾向于水平繪制它們，較新的提交向右，而不是像git log --graph較新的提交向頂部繪制它們：
C--D--E <-- your-branch
/ \
A--B---------F <-- master (HEAD)
也就是說，您使用名稱master作為當前名稱，這樣git log --graph --first-parent master會顯示 commits F、 then B、 then A，但git log --graph沒有分支 name也會如此master。
現在假設我們有這個而不是上面的：
C--D--E <-- your-branch
/ \
A--B---------F <-- dev (HEAD), master
這是同一張圖，因此git log --graph --first-parent master將從 commit 開始F，然后跳回 commit B——跳過第二個父節點E及其祖先——并顯示您的期望。
現在，使用相同的設定，讓我們運行并記下它根本不會更改提交git commit --amend的事實。相反，它創造了一個新的（并且據說是改進的），就像但有一些不同的東西：在這種情況下，我們更改了日志訊息。所以現在我們有：FF' F
C--D--E <-- your-branch
/ |\
A--B-------\-F <-- master
\ \
--------F' <-- dev (HEAD)
運行git log --graph --first-parent，您將按順序看到新的F', then B, then 。A但唯一更新的名稱是，不是。所以將顯示 commit ——原始的，根本沒有實際修改的提交——然后是.git commit --amenddevmastergit log --graph --first-parent masterFBA
這對您來說意味著您必須非常小心。git commit --amend它需要與 相同的注意git rebase，它也可以通過將現有提交復制到新的和假定改進的替換提交來作業。 原始提交始終保留。 任何提交都無法更改，即使是 Git 本身！ 如果沒有人再看到原始提交，那么看起來好像舊提交已更改為新提交，前提是您從未查看原始哈希 ID。1 但他們沒有：原始提交仍然存在，帶有原始哈希 ID。我們只是使用更新的名稱來查找新的提交，而不是舊的。
需要小心是因為有些人——在這種情況下，甚至可能是你自己——仍然會有參考舊的、未改進的提交的名稱。當使用這些名稱查找提交時，他們將看到舊的提交。
1到底是誰做的？
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/466864.html
標籤：混帐