我開始編輯一個從我玩了一會兒的故障存盤庫下載的專案。在我下載專案并繼續在本地編輯它之前，已經完成了很多自動提交。問題是自動提交可能包含敏感資訊（例如我的電話號碼或帶有訪問令牌的 url）我不想出現在存盤庫中，而且它使專案看起來有點混亂。
我想保留749bcc4并稍后洗掉cd1ee76回購中的早期提交，而不會影響較新的提交。
我git log現在看起來像這樣：
<17 more recent commits made by me>
4dea670 (Supress logs during tests, 2022-06-04)
8915b33 (Webhook subsciption tests, 2022-06-04)
f189b0b (Functioning test template with chai-http added, 2022-06-04)
749bcc4 (Replies automatically to every message received, 2022-06-04) <-- I pickup the project and get serious about it
cd1ee76 (??? Checkpoint ./app.js:44684210/652, 2022-05-12) <-- Automatic checkpoint (I am technically not the author of these)
b8531dc (???? Checkpoint ./README.md:44684210/2364 ./app.js:44684210/12304, 2022-05-11)
a92f72a (???? Checkpoint ./package.json:44684210/231 ./app.js:44684210/95 ./README.md:44684210/164, 2022-05-11)
11bb69b (???? Checkpoint ./app.js:44684210/242, 2022-05-11)
8482190 (???? Checkpoint ./README.md:44684210/16, 2022-05-11)
7123b4c (??? Checkpoint ./package.json:44684210/3241, 2022-05-11)
<And like 50 more checkpoint commits>
有什么方法可以洗掉它們，然后強制推送到遠程倉庫？我正在單獨使用那個遙控器（可能很快就會改變），所以推送對任何人來說都不會有問題。
uj5u.com熱心網友回復：
總結：不是，是的。您需要從 GitHub 管理員那里獲得幫助。
長
您可以在 Git 存盤庫中“編輯歷史記錄”——但其作業方式是將（部分或全部）舊提交復制到新提交和改進提交，然后還必須復制所有后續提交。如果你是一個人作業，那么沒有其他人會對這種“復制/重做舊的提交，然后改用新的改進的提交”有任何問題，所以你可以安全地使用. 但是您特別提到了 GitHub，在這里您進行新提交的事實很重要。git push --force
讓我們看看 Git 內部是如何作業的：
每個提交都有編號，并帶有一個特定于該特定提交的唯一編號。（Git 將此稱為哈希 ID或物件 ID。每個存盤庫中的每個提交都有一個唯一編號。不是“大部分唯一”，不是“某種唯一”，而是唯一的。這就是兩個 Git，當他們見面并互相打招呼時
git push或者git fetch，找出他們有哪些提交而另一個沒有；他們使用此資訊將提交從發送者提供給接收者，而無需重新提供接收者已經擁有的東西。）每個提交都存盤兩件事：它的檔案快照和一些元資料，或者關于提交本身的資訊。這些是完全只讀的：任何提交的任何部分都不能更改（這就是哈希 ID 技巧的作業原理）。元資料包括您的姓名和電子郵件地址（來自
user.name和user.email），還包括一些早期提交的原始哈希 ID。
提交（和其他支持物件）存盤在一個大型的全物件資料庫中，Git 可以在其中查找它們。要在此資料庫中查找物件，Git需要哈希 ID。因此，如果 Git 沒有第二個資料庫，我們都必須記住我們的哈希 ID（例如，是您的一個，但這是一個縮寫，我們可能必須記住完整的 40 個字符）。749bcc4
我們只需要保存某個鏈中最后一次提交的哈希 ID，因為 Git 在每個提交的元資料中存盤了該鏈中上一次提交的哈希 ID。也就是說，如果您正在處理 branch main，Git 有一個名稱（在這種情況下），它包含鏈中最后一次提交main的哈希 ID 。我們說這個名稱指向最后一次（或提示）提交。該提交包含倒數第二個提交的哈希 ID，其中包含倒數第三個提交的哈希 ID，依此類推：
... <-[third-to-last] <-[second-to-last] <-[last] <--main
由于每個提交都有一個唯一的哈希 ID，我們所要做的就是向 Git 提供這些哈希 ID 中的任何一個，Git 就可以檢索提交。但我們不必記住所有這些，甚至最后一個，因為名字 main包含最后一個。所以我們可以告訴 Git：查找名稱main，獲取哈希 ID，然后獲取提交。Git 這樣做并找到最后一次提交，其中包含上一次提交的哈希 ID。Git 可以查找它并找到提交，其中包含上一次提交的哈希 ID ......等等，永遠向后，一次提交一次，直到 Git 得到第一次提交。那個沒有以前的哈希 ID（因為它不能，所以沒有以前的提交），所以這一切終于停止了。
要進行新的提交，我們“檢查”分支，做通常的事情，運行和git commit. Git 構建快照和元資料并設定新的提交，以便它向后指向現在的最后一個提交，其哈希 ID 在名稱中。然后 Git 把它寫出來，一直凍結它。這分配了一個新的唯一哈希 ID，并且剛剛進行的新提交是鏈中的最后一個提交，因此 Git 現在將該哈希 ID 寫入名稱 main中——瞧，圖片保持不變，除了現在有一個新的“最后一個”犯罪。
考慮到上述情況，歷史重寫變得簡單（ish）
假設我們有一個提交鏈，我們將像這樣繪制，使用單個大寫字母代表提交：
...--F--G--H--I--J <-- main
（我對箭頭變得懶惰了，但是從 commit 到 commit 的箭頭仍然指向后面：Jto I，Ito H，等等。）假設我們不喜歡commit，H無論是在快照中，元資料中， 或兩者。為了解決這個問題，我們讓 Git通過它的原始哈希 ID檢查commit G——使用這樣的工具git rebase，我們不必剪切和粘貼太多的哈希 ID；這是一個錯誤的秘訣——它給了我們這個：
H--I--J <-- main
/
...--F--G <-- temporary-branch (HEAD)
使用臨時分支，我們進行了一個新的改進提交，替換了 H，我們不妨稱之為H'：
H--I--J <-- main
/
...--F--G--H' <-- temporary-branch (HEAD)
Everything was fine with commits I-J so we copy them (or let git rebase do it, which git rebase does using git cherry-pick). We can't alter commit I: we can't change anything about any commit. But we can easily make a new commit, I', that points to H' instead of H:
H--I--J <-- main
/
...--F--G--H'-I' <-- temporary-branch (HEAD)
We do the same for J:
H--I--J <-- main
/
...--F--G--H'-I'-J' <-- temporary-branch (HEAD)
and now we use the fact that people find commits by name: we tell Git to wrestle the name main around so that instead of pointing to J, it points to J'. We switch back to branch main and delete the temporary name so that we have:
H--I--J [abandoned]
/
...--F--G--H'-I'-J' <-- main (HEAD)
As long as we look up commits by name, we'll never see the old ones.
(The mechanism you'll probably want to use, to get the new-and-improved commits, is git rebase --interactive which lets you use squash and/or fixup commands to combine commits. Squashing a bunch of "checkpoint" commits together effectively replaces that whole series of checkpoint commits with a single commit that produces the same final result.)
But what happens to the old commits?
The key to your particular problem comes in here: we're using the new and improved commits, having abandoned the old commits. But they still exist. Git has a mechanism—actually a whole complicated Rube-Goldberg-esque series of mechanisms—by which an unused, abandoned commit is eventually removed for real (called "pruning" and/or "garbage collection" depending on which level of the Goldberg machinery you want to work with). The commits fall away some time after 30 to 90 days. Exactly when, we don't control, unless we get deep enough into the machinery using git gc for instance (GC stands for Garbage Collection, although I sometimes call it the Grim Reaper Collector, or in this case the Goldberg Collector). Once Git has garbage-collected the abandoned commits, they're really gone—from this copy of the repository, that is.
The way Git works overall, everyone has a full copy of all commits. So if someone else, in some other Git repository, has the "bad" commits that you want gone ... well, now we're getting into the danger territory.
In this case, GitHub is the "other Git". They have a copy of your repository. You will use git push --force or equivalent to send them your H'-I'-J' new commits and then command them to set their main to point to J' instead of J, so that their repository will look exactly like yours:
H--I--J [abandoned]
/
...--F--G--H'-I'-J' <-- main (HEAD)
You now cross fingers and hope that some time after 30 to 90 days, GitHub will garbage-collect the H-I-J sequence. But if you know the hash ID, you can feed that hash ID directly to software over on GitHub, and thereby access and read those commits.
GitHub don't throw out the garbage
Now we hit the big snag: while you made GitHub's repository abandon commit J, they never take out the trash, as it were. They never garbage-collect abandoned commits. This isn't a promise, and maybe someday they will do it. Maybe someday in the past they did do it. It's just a state-of-affairs that we see today: right now they don't. (This all has to do with GitHub's "fork" mechanism; if a repository has never been forked, GitHub could GC it safely, but if it has forks, they'd have to create a lot of really complicated new Rube Goldberg machinery.)
What this means is that if someone "out there" has memorized, or can guess, a raw hash ID for the commits you'd like GitHub to throw out, that someone can find your old abandoned commits over on GitHub. They can read them and thereby see the things you wish they couldn't.
GitHub admins can go into the GitHub storage and force these abandoned commits to be GC-ed for real. Having them do that will get rid of the commits from the GitHub copy. If nobody else has made a copy of the GitHub copy in the meantime, then your abandoned commits are gone from every copy in the universe, and then you're safe.
(This is why the general rule is that if some secret has ever been published on GitHub, we should just assume that everyone knows it now.)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/493156.html