如何從具有提交分配的拉取請求中洗掉某些檔案？-有解無憂

概括地說，假設我有一個包含以下目錄的專案。在推送和執行拉取請求后，我將如何最終洗掉 file2.txt？

app/someFolder
  - file1.txt
  - file2.txt
  - file3.txt

假設我的提交是這些

Commit 1       
  file1.txt
    Hello World
  file2.txt
    Cool, Superb
  file3.txt
    December 2

git 添加。
git commit -m "commit 1"
git push --set upstream origin someBranchOnRemote

 Commit 2  
   file1.txt
     Hello World
     Boss Bass

git 添加。
git commit -m "commit 2"
git push

 Commit 3
   file3.txt
     December 3

git 添加。
git commit -m "commit 3"
git push

因此，如果我要執行拉取請求，檔案將如下所示

file1.txt
  Hello World
  Boss Bass
file2.txt
  Cool, Superb
file3.txt
  December 3

現在我將如何更新拉取請求，以便不包含 file2.txt？假設散列是 hash1、hash2 和 hash3。我想要在拉取請求中的最終輸出是

file1.txt
  Hello World
  Boss Bass
file3.txt
  December 3

uj5u.com熱心網友回復：

TL; DR：你想git rebase -i后面git push --force或git push --force-with-lease。但請閱讀以下內容。

首先，附注：Git 本身沒有“拉取請求”；這些是某些托管站點（例如 GitHub 和 Bitbucket）的功能。它們在每個托管站點上的作業方式往往相似，但每個站點在此處都有自己的怪癖和行為。您可能必須針對您使用的任何托管站點調整此答案。

順便說一句，PR 是您向某人提出的請求，他們將您所做的一些提交合并（或“獲取并合并”=“拉”）。在 Git 中，你并沒有真正合并一個分支：你實際上合并了commits。當您運行時，您將合并的提交git merge是來自某個提交鏈的提交，由該鏈中的最后一個提交結束。

即：提交表單鏈。每次提交在一個鏈記住其前身的原始散列ID提交。我們說一個提交指向它的父提交，我們可以這樣畫：

... <-E <-F <-G <-H

一個分支名，然后簡單地提供的原始哈希ID去年鏈條，從Git會發現所有先前提交承諾：

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

當您發出拉取請求時，您：

首先分叉和/或克隆一些存盤庫，以便您獲得其他人擁有的所有提交；
創建一個新的分支名稱，以便您有一個指向最后一次提交的名稱，該名稱也是他們的提交之一；
進行新的提交，以便您的分支名稱前進。

例如，假設他們的提交通過（然后停止）我在上面繪制的提交為E. （順便說一下，我只是出于懶惰才停止在提交之間繪制箭頭：提交總是向后指向，所以每當你看到一條連接“線”時，它實際上是一個向后指向的“箭頭”。）

也就是說，他們在他們的存盤庫中有一些提交序列：

...--D--E   <-- somebranch

您現在在您的存盤庫中有：

...--D--E    <-- origin/somebranch

您創建一個指向 commit的新分支名稱E：

...--D--E    <-- my-fancy-new-feature, origin/somebranch

現在您在“打開”這個新分支時進行新的提交：

...--D--E    <-- origin/somebranch
         \
          F   <-- my-fancy-new-feature (HEAD)

這是影響三個檔案的“哈希 1”或“提交 1”。CommitF包含所有檔案，因為所有提交始終具有每個檔案的完整快照，但是commit中的檔案與commitF中的所有檔案都相同E，除了您更改的三個檔案。（Git 巧妙地對相同檔案進行重復資料洗掉，因此這也不會占用太多空間。）

現在提交F存在，你再做一個新的提交G：

...--D--E    <-- origin/somebranch
         \
          F--G   <-- my-fancy-new-feature (HEAD)

這是您的“提交 2”，它僅更改檔案file1.txt. CommitG仍然擁有每個檔案，只是它的副本file2.txt與 commit 的副本匹配F；它的副本file3.txt與 commit 匹配F；及其所有其他檔案與提交F 和E.

最后，添加 commit H：

...--D--E    <-- origin/somebranch
         \
          F--G--H   <-- my-fancy-new-feature (HEAD)

在提交中，H您已替換file3.txt為修改后的檔案；file1.txt并file2.txt匹配 commit 中的副本G，依此類推。

這又讓我們回到你的問題：

...我將如何更新拉取請求，以便我file2.txt不被包括在內？

Git 基于commits而不是檔案作業，你的 PR 說請合并 commitH。要更改此設定，您必須：

somehow change commit H, or
change the PR so that it lists some other commit hash ID, not H.

It's literally impossible to change anything about any commit, ever, so the first idea is right out.

Whether it's possible to change the PR so that it lists some other commit, depends on the hosting site. If the hosting site is particularly obnoxious, you might have to close this PR, and open a new one later. But GitHub at least will let you update the PR quite simply.

Your first task, though, is to come up with new commits. You don't want file2.txt changed, but it was different in commit F (vs commit E), so commit F itself is bad in some way. This means you need a new replacement for commit F. Let's call this F' to indicate that it's a lot like F, but it will have a different raw hash ID.

To get commit F', we want to "copy" commit F without quite committing yet. We'll start by checking out commit E. We could create another new branch name, but we could also use Git's "detached HEAD" mode, like this:

...--E   <-- HEAD, origin/somebranch
      \
       F--G--H   <-- my-fancy-new-feature

Now we'll run, say, git cherry-pick -n and give Git commit F's hash ID, or something equivalent: my-fancy-new-feature~2 for instance. Git will copy the effect of F but not commit anything yet—we'll have some work in progress that we can commit—and now we have a chance to undo the change to file2, with, e.g., git restore:

git restore -SW --source=origin/somebranch file2.txt

A quick git status and git diff --cached will show that we've now retained the updated versions of file1.txt and file3.txt, but gone back to the original file2.txt from commit E as found by the name origin/somebranch.

We can now run git commit to make F':

       F'  <-- HEAD
      /
...--E   <-- origin/somebranch
      \
       F--G--H   <-- my-fancy-new-feature

Commit G affects file1.txt only, so we can just copy it wholesale, with git cherry-pick, which will not only figure out what it changed and apply it, but also make a new commit, re-using the original commit's message:

       F'-G'  <-- HEAD
      /
...--E   <-- origin/somebranch
      \
       F--G--H   <-- my-fancy-new-feature

You might wonder why we copy G to G', rather than just using G itself. The answer is simple: nothing about commit G can ever change. The arrow coming out of G, pointing to F, is part of G. It can't change! Commit G will forever point back to commit F, never to commit F'. So we have to copy G.

Also, commit G has the wrong copy of file2.txt in it, of course, which would also force us to copy it—but anything that forces us to copy the commit, forces the whole thing. Note that when we do "copy" G with cherry-pick, Git compares the snapshot in G to that in F to see what changed. Since file2.txt in this pair-of-commits did not change, Git won't change file2.txt in G' vs F'. So G' will have the same file2.txt as F', and F' has the same file2.txt as E.

Now, for the same reasons, we need to copy H, which we can do with one more git cherry-pick command. The result is:

       F'-G'-H'  <-- HEAD
      /
...--E   <-- origin/somebranch
      \
       F--G--H   <-- my-fancy-new-feature

Now that we have the right commits, all (all?!) we have to do is to get the name my-fancy-new-feature to point to H' instead of H. We can do that in various ways, such as git checkout -B my-fancy-new-feature or git switch -C my-fancy-new-feature. The final result here will be:

       F'-G'-H'  <-- my-fancy-new-feature (HEAD)
      /
...--E   <-- origin/somebranch
      \
       F--G--H   ???

What happens to the F-G-H chain, that Git used to find by looking at the name my-fancy-new-feature? The answer is: nothing happens to it. It's still there. It's just that now, it goes unused. These aren't the ~~droids~~ commits you're looking for, so we just make sure that these aren't the commits we find.

We now have the right commits, locally, in this repository. Now we have to get them to the hosting site, and get the hosting site to update the pull request. To do that on GitHub, we just push the new commits to GitHub, telling the Git over on GitHub to replace the F-G-H commits in its repository with our new F'-G'-H' chain.

Git in general is greedy for commits, so if we just run a regular git push origin my-fancy-new-feature, they—the Git over on GitHub, operating on your repository over there—will reject our attempt to do this. They will say, in effect, No! If I do that I'll lose the F-G-H chain! (As with our own repository, the commits won't be gone, they just won't be findable by the name my-fancy-new-feature any more. But that's enough for them to reject the request.) You'll likely get a suggestion that you pull (i.e., fetch and merge) the commits from GitHub: they don't realize that they got them from you in the first place, and that you're telling them these are the new and improved replacements so you should ditch the old ones in favor of these new-and-improved ones.

To make them realize that, you need some kind of forced-push (not Star Wars style "force", but just the regular English-language meaning). Git has several kinds and you can use any of them here, but --force-with-lease has a safety feature (that shouldn't matter here: if it does, something has gone not-according-to-plan, and the safety feature detects that) and is generally the way to go.

Making this easy(ish)

The sequence above has lots of Git commands in it, many of them tricky (I didn't show the full commands for multiple reasons). We can reduce that to a smaller number of much-less-tricky commands using git rebase -i. There's still one big bit of trickiness though.

Running:

git switch my-fancy-new-feature
git rebase -i origin/somebranch

is how we start. The rebase operates on the current branch, so we begin by checking out my-fancy-new-feature (you can use git checkout or git switch here, or do nothing if you're already on it).

What rebase does is:

list out commits to copy (hash IDs);
use Git's detached HEAD mode to begin copying; and
start cherry-picking.

Once it's all done, it fixes up the detached HEAD by moving the branch name to the last of the copied commits (H' in our case). So that automates a lot of the hard work.

Rebase in general is what we use when we have some commits that we mostly like, but there is something about those commits that we don't like. Since nothing about any existing commit can change, rebase works by copying the commits. The new copies can be changed along the way, before we commit them.

The interactive rebase in particular gives us more opportunities for change. A plain rebase just copies everything without giving us a chance to fix stuff, which is useful for moving commits—for taking a chain like this:

          A--B--C   <-- topic
         /
...--o--o--o--o   <-- mainline

and copying it to:

          A--B--C   ???
         /
...--o--o--o--o   <-- mainline
               \
                A'-B'-C'  <-- topic

so that the commits now come at the end of the mainline, instead of sprouting from an earlier point. That's not what we want here: we want to change some of the files in one of the commits.

So, interactive rebase, instead of just planning out all the cherry-picks and then starting them, writes out an instruction sheet. This instruction sheet lists the cherry-picks, using the word pick for each one:

pick hash1  subject
pick hash2  subject
pick hash3  subject

Then, once the instruction sheet is written, git rebase -i opens an editor on the instruction sheet so that we can change the commands.

In our case, we don't want to just pick commit #1 as-is. We want a chance to change it. So we will change pick to edit. We do want to pick #2 and #3 as is, so we'll leave those alone. Then we write out the instruction sheet and exit the editor,¹ to return to the cherry-pick action.

Having changed the first pick to edit, Git will cherry-pick the first commit but then stop to let us fix it up. There's one thing that's particularly tricky here: Git has actually made a temporary commit at this point, so when we do fix it up, we have to run git commit --amend.² We can now do our git restore as I described earlier, then run git commit --amend:

git restore -SW --source origin/somebranch file2.txt
git commit --amend

(note: --source=origin/somebranch and --source origin/somebranch work the same way here, so you can use either one).

Once we're done fixing up that edit-able commit, we tell Git to resume the rebase:

git rebase --continue

This will finish off all the remaining cherry-picks, then re-arrange the branch name and re-attach our HEAD to our branch, and now we have what we wanted:

       F'-G'-H'  <-- my-fancy-new-feature (HEAD)
      /
...--E   <-- origin/somebranch
      \
       F--G--H   ???

We're now ready to run:

git push --force-with-lease origin my-fancy-new-feature

and if we're talking GitHub, the "update the PR without closing and re-opening" is now done.

We used a total of five or six Git commands, about half of what we needed earlier, and we didn't have to do anything tricky except for the interactive rebase "edit" step. Everything else is pretty straightforward here.

¹Some editors don't exit: you start them up early and then they hang around forever. Examples include many cases of Emacs, Sublime, and Atom. If you're using one of these editors, you have to make them interact well with Git; that's a matter for that particular editor, but most of these editors these days have a --wait flag that arranges all of that to work right.

²該--amend標志似乎改變了一個提交，與上面我們不能改變任何提交的說法相矛盾。這里的骯臟秘密是--amend 不會改變提交。相反，它只是再次提交。因此，當我們使用時，--edit我們會生成額外的、毫無意義的“垃圾”提交。但是 Git 中的提交非常小而且便宜，所以這樣做總比避免它好。Git 最終會自行清理，盡管這通常需要一個多月的時間。Git 所做的清理/清潔作業有點慢，但在 5 分鐘內清理一個月的垃圾，而不是立即清理每一點垃圾，實際上是一個非常實用的權衡。

uj5u.com熱心網友回復：

根據您的要求，我會洗掉該檔案，從中進行新的提交并將其推送到您的分支。這樣，PR 中將有第 4 次提交洗掉檔案，最終結果將如您所說。

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/361394.html

標籤：混帐版本控制

上一篇：終端中的Git版本與VScode不同

下一篇：gitrebase忽略沖突