如何在互動式變基期間取消暫存檔案（從舊提交中洗掉檔案）？

我在Pro Git中閱讀了有關互動式變基以更改多個提交的書。所以我正在做git rebase HEAD~3，改變了一個我想修改的edit。然后我可以通過git commit --amend. 并添加了一個檔案，git add file3之后git commit --amend開始輸出“3個檔案已更改”而不是之前的“2??個檔案”。但是如何洗掉檔案？為什么既不作業git restore --staged file1也不git reset HEAD file1作業？（ git commit --amend遺體“3 個檔案已更改”的輸出和git log --patch仍然顯示file1最近修改的提交訊息的提交的輸出）。

我使用網路搜索并閱讀了什么是`git restore`命令以及`git restore`和`git reset`之間有什么區別？（如上所見，同時嘗試了restore和reset），從 Git 提交中洗掉檔案（討論最后一次提交），洗掉舊提交中提交的檔案（據我所知，git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch <path_to_file>" HEAD從分支中的所有提交中洗掉檔案）。

也沒有贊成的答案洗掉對舊檔案的更改，已經推送，git commit？和

git rebase -i HEAD~3 //Change "pick" to "edit" for commit to change
git reset HEAD^ -- F2 //reset F2 to previous version in staging area  

洗掉檔案需要重置整個提交嗎？在變基期間不能洗掉單個檔案？

uj5u.com熱心網友回復：

當您談論在互動式變基期間洗掉檔案時，您可能意味著以下兩件事之一：

• 使檔案匹配上一次提交。有些人會稱之為洗掉檔案的更改，并且由于有些人認為提交是更改，因此有些人會將其縮短為洗掉檔案。

• 從字面上洗掉該檔案，以便您的新提交和改進的提交省略該檔案。

兩者都相對容易做到。在我說如何做之前，我先介紹一些背景知識。

背景

要了解您在做什么以及為什么，擁有正確的 Git 提交心智模型會有所幫助：

• 每個提交都有一個唯一編號（哈希 ID或OID，其中 OID 代表物件 ID）。提交的編號是 Git 真正找到提交的方式：分支名稱實際上并不重要。

• 所有 Git 提交——事實上，所有 Git 內部物件——都是完全只讀的。你不能改變一個提交，所以這不是git rebase真正的。

• 每個提交存盤兩件事：（a）所有檔案的快照，以及（b）一些元資料。

提交快照中的檔案經過壓縮和 Git 化，重要的是，當某個檔案的內容與某個其他檔案的內容匹配時，會進行重復資料洗掉（在提交內和提交之間）。因此，大多數提交主要包含大多數先前提交的所有檔案這一事實不會導致存盤庫膨脹：這些重復的檔案只存盤一次。只要您不在 Git 中存盤大的、不可壓縮的二進制檔案，Git 就可以無形地處理這一切，而且非常好（如果這樣做，那么 Git 處理得不好，并且存盤庫會膨脹并變得無法使用）。但這也意味著提交不存盤更改。

提交中的元資料記錄了諸如誰提交、何時以及為什么提交（他們的日志訊息）之類的東西，但它也記錄了對 Git 內部操作至關重要的資料：每個提交都存盤一個父提交哈希 ID 的串列。這個串列通常只有一個元素長，為每個提交提供一個父級。父提交也有一個快照，為了將提交轉換為更改（用于查看目的），Git 提取兩個快照并查看哪些檔案被更改。由于重復資料洗掉，Git 可以將其短路，根本不用費心提取相同的檔案；然后它只需要為兩個提交中不匹配的檔案提出一個更改配方。這就是你看到的git show或git log -p：從提交的（單個）父級快照到提交的快照的差異。

因為提交是只讀的，并且只有 Git 本身可以讀取它們，所以我們實際上并不處理或使用提交。相反，當我們選擇要使用的某個提交時，我們讓 Git將提交（例如解壓縮或解壓縮某些存檔）提取到一個作業區域中，Git 將其稱為我們的作業樹或作業樹。雖然這些作業樹檔案是從Git 中提取的，但在您完成作業時，它們實際上根本不在Git中。

因為提交是只讀的，git rebase不能修復任何錯誤的提交，也不會git commit --amend更改提交。相反，Git 利用了這樣一個事實，即人類（與 Git 本身不同）永遠不會^通過哈希 ID 找到提交。相反，我們使用分支名稱。分支名稱只是保存了我們想要宣告為“分支的一部分”的最后一次提交的哈希 ID 。然后，該提交在其元資料中保存上一次提交的哈希 ID，在其元資料中保存另一個更早提交的哈希 ID，依此類推。這產生了一個簡單的后向鏈：

... <-F <-G <-H   <--branch

其中分支名稱包含鏈中最后一次提交的哈希 ID H，并且一切都從那里向后作業。

當我們以正常的日常方式添加提交時，Git 會創建一個新的（只讀）提交I，其父級為H，將其添加到鏈中，并將新提交的哈希 ID 寫入I分支名稱：

...--G--H--I   <-- branch (HEAD)

要“修改” commit H，Git 只需撰寫新的 commitI并以 commitG作為其父級，而不是 commit H，結果是：

       H
      /
...--G--I   <-- branch (HEAD)

提交H仍然存在，但除非我們記住它的哈希 ID，否則我們將永遠不會再看到它。（Git可以，只要 Git 能找到它的哈希 ID。）

變基只包括進行不止一個新的和改進的提交。如果我們有：

...--F--G--H   <-- main
         \
          I--J   <-- feature (HEAD)

并且我們希望修改I后出現在它之后 H而不是之前/與之并行，我們進行新的快照和元資料提交I'（否則看起來像I，除了我們將H的快照作為我們的“基礎”和“重新添加”我們的更改I，因此“重新基礎”-ing I）：

             I'  <-- HEAD [detached]
            /
...--F--G--H   <-- main
         \
          I--J   <-- feature

然后我們重復此J操作以獲取J'：

             I'-J'  <-- HEAD [detached]
            /
...--F--G--H   <-- main
         \
          I--J   <-- feature

一旦我們將所有提交復制到新的和改進的提交，我們讓 Git 移動名稱 feature以指向最后復制的提交：

             I'-J'  <-- feature (HEAD)
            /
...--F--G--H   <-- main
         \
          I--J   [abandoned]

原始提交仍然存在；我們只是找不到他們。

¹(insert Gilbert & Sullivan HMS Pinafore routine here)

Interactive rebase

Interactive rebase uses the same process as non-interactive rebase,² but lets us stop and make adjustments. To do that, Git provides us with an instruction sheet. It contains, initially, a series of pick commands for each commit that we will copy. These instruct Git to run git cherry-pick, which is the step that copies a commit, like I to I' above.

Changing pick to edit makes Git do the cherry-pick, but then stop in the detached-HEAD mode. Note that here we're copying I to I' and placing it in the same physical position as before, rather than moving it to come after commit H:

          I'  <-- HEAD [detached]
         /
...--G--H   <-- main
         \
          I--J   <-- feature

Now that we're in this state, we can use git commit --amend to make yet another commit, I". In this commit, we can store any snapshot we like, and use any commit message we like. The parent of I" will be H, the same as the parent of I and I'.

The snapshot that goes into the new commit has the same source as any new Git commit: it comes from Git's index AKA staging area. This currently contains all the files from commit I', which match all the files from commit I (and hence do and will use no space as they're all duplicates that are pre-de-duplicated already). These are the Git-ified copies of the files that are also in your work-tree. So you can modify or remove the file in your work-tree and run git add:

vim foo.py
git add foo.py

or:

rm foo.py
git add foo.py

The git add step tells Git to make the index copy match the working tree copy, by reading and compressing and de-duplicating the file, or—after removing foo.py—removing the index copy entirely. Or:

git rm foo.py

combines the rm and git add into a single step. Either way we've arranged for the correct (updated or removed) file to be in Git's index, so we now run git commit --amend, just as you did:

git commit --amend

This shoves commit I' up out of the way, leaving commit I" pointing to H:

         I'  [abandoned]
        /
        | I"  <-- HEAD [detached]
        |/
...--G--H   <-- main
         \
          I--J   <-- feature

Running git rebase --continue tells the rebase code to proceed on to the next instruction in the instruction sheet: another pick, or edit, or reword, or whatever. Once the last instruction has been followed, rebase will yank the branch name around as before:

         I'  [abandoned]
        /
        | I"-J'  <-- feature (HEAD)
        |/
...--G--H   <-- main
         \
          I--J   [abandoned]

(The abandoned commits sit around for a while—at least 30 days by default, in the usual setup—and then Git eventually notices that they've gone unused for long enough, drops the reflog entries that are keeping them alive, and purges them for real. Until then, though, you can easily get the originals back. Note that the special name ORIG_HEAD also remembers commit J for a while, until you do something else that has Git overwrite ORIG_HEAD with another hash ID. Right after a successful rebase, if you don't like the result, ORIG_HEAD works just as well as the reflog entry in branch@{1}.)

²In older versions of Git, there were numerous technical differences. In modern Git, these are largely gone now, though you can still invoke them on purpose if you really want to. I will also elide a number of optimizations Git normally uses for the kind of interactive rebase you'll be doing, that do make things better for Git but don't change the final outcome here.

We can now see what git reset or git restore will do

Why neither git restore --staged file1 nor git reset HEAD file1 works?

Both git reset and git restore will read a file's content from somewhere and write that file's content to somewhere. The git reset command itself is absurdly complicated, so it's better to stick with the newer, better-focused (more limited) git restore in my opinion, but either one will work: we just have to know several things here.

git reset HEAD^ -- F2 //reset F2 to previous version in staging area

Here, we're using git reset, not git restore, in its restore-one-file mode of operation. If we use:

git reset HEAD -- file1

we are telling Git: read the Git-ified copy of file1 from the commit specified by HEAD. If we use:

git reset HEAD^ -- F2

we are telling Git: read the Git-ified copy of F2 from the commit specified by HEAD^.

In both cases, having read the specified file from the specified commit, git reset writes the (Git-ified, pre-de-duplicated) content into the index / staging-area, ready to go into the new commit. The name of the file in the staging area is the same as the name of the file in the chosen commit (file1 or F2). The working tree copy of the file is not changed here! This is undesirable, since it makes it hard to see what you're doing, but since Git isn't actually using the working tree copy at this point, it's not exactly harmful right now either.

Using git checkout is better:

git checkout HEAD^ -- F2

This form of git checkout—which, like git reset, is absurdly complicated, which in turn is why git checkout was split into git switch and git restore in Git 2.23—reads a file from the specified commit and writes it to both Git's index and your working tree. This makes it much easier to see what you have done, since the working tree copy is now obvious.

If your goal is to make the copy of F2 in the new I" commit match the copy in commit H, these HEAD^ forms of the command will do the trick. The reason is that HEAD currently names commit I', the copy of commit I. I''s parent is H, so retrieving the copy of file F2 (or file1) from commit H will restore the index and working tree version to match that in H, and now the commit you make with git commit --amend—the I" commit—has in it the same copy of that file (de-duplicated).

If your goal is to truly remove F2 entirely, so that commit I" has no file F2 at all, git rm F2 (or git rm -- F2 to avoid problems with files named --cached, for instance) will do that.

If we want to make F2 match the copy in H, but using git restore to avoid the overly-complicated-checkout-command-related errors, we'd run:

git restore -SW --source=HEAD^ -- F2

for instance. This does the same as the git checkout: we specify HEAD^ as the source for the file, -S (--staged) to tell git restore to write the file to the staging area, and -W (--worktree) to tell git restore to write the file to our working tree.

Note that in all cases, our goal here is to make the index contain the correct files as git commit --amend is going to make the new snapshot from Git's index. Being humans, we should generally update the working tree copy of these files at the same time, since we can't see the index (staging area) copy, but we can see, in whatever editor or file viewer we prefer, the working tree copy.

We must also remember that if and when we run git status, Git will run two git diff --name-status operations for us:

• One will compare the HEAD commit vs Git's index. But the HEAD commit is commit I', not commit H! So we need not to pay too much attention to this.
• The other will compare Git's index vs our working tree. This diff should, ideally, be empty, so that we're looking at the same files in our working tree as Git will be using in our next commit.

The reset --soft option

There's one other thing we can do, which I myself never actually do: instead of git commit --amend, we can start out the whole amending process with git reset --soft. That is, we start git rebase -i, change one pick to edit, write out the instruction sheet, and let rebase begin. We're now in this state:

          I'  <-- HEAD [detached]
         /
...--G--H   <-- main
         \
          I--J   <-- feature

The git reset --soft command lets us move the detached HEAD without changing either Git's index or our working tree at all. Running git reset --soft HEAD^ produces this:

          I'  [abandoned]
         /
...--G--H   <-- main, HEAD [detached]
         \
          I--J   <-- feature

That is, we give up commit I' right away. We have most of what we want in Git's index / staging-area and in our working tree. By giving up I' entirely, we now have things arranged as if we'd never made commit I at all: the current commit is now H, not I.

We can now git restore -SW --source HEAD -- file1, if that's what we want. In fact, with -S, --source HEAD is the default, so we can shorten this to:

git restore -SW -- file1

這會將commit 中的file1commit ——我們H現在調整的——復制HEAD到 Git 的索引和我們的作業樹，丟棄我們在 commit 中所做的任何更改I。現在git status，git diff --cached如果我們第一次執行此提交，請給我們相同的結果。

（如果 的edit模式rebase -i總是自動完成這可能會很好，但事實并非如此，現在改變它為時已晚。）

標籤：

上一篇：撤消功能分支合并

下一篇：如何為此XML正確撰寫DOMXPath查詢？