使用過濾器分支更改作者名稱後Git提交重複

Question

我們接受了來自用戶的使用其作者名稱中的字符的pull請求，這些字符在一些git工具中導致問題。在試圖解決這個問題，我們按照說明這裏修改提交歷史： https://help.github.com/articles/changing-author-info/

現在我們大部分的提交是重複的： https://github.com/CreateJS/EaselJS/commits/master/

我找到了潛在的解決方案，如： git filter-branch duplicated commits

但是，我沒有看到另一個分支，只是重複提交，並且在我們發現之前做了另一次提交。我想確定我們不會把這件事搞糟。任何幫助表示讚賞

Answer 1

這是不是從直接鏈接到github上清楚，但我克隆回購，這使得它更加明顯：

• 你做的filter-branch本身按指令。這造成了一大堆新的提交。

• 但你（它看起來像你）合併了老鏈提交與新鏈的提交（加上一個額外的承諾，「北京時間清理和bug修復」），而不是力 - 覆蓋舊的存儲庫以放棄所有舊的提交。

如果您按日期查看它們，這會使所有提交看起來像重複（因爲它們低於合併兩個鏈的點）。

如果通過圖形型拓撲爲了查看它們，你可以看到更容易這是怎麼約（注意，這是截斷右邊以適合窗口）：

* f721f0c (HEAD, origin/master, origin/HEAD, master) Merge branch 'master' of 
|\ 
| * 97ffb07 Documentation updates. 
| * 3e777f2 Update docs and VERSIONS. 
| * 1f32407 Swapped append/prepend naming. 
| * dadd1c9 Fixed example in Graphics.append() docs. 
| : 
| :  [massive snippage, graph modified to show connections] 
| : 
| * d0d7f36 Merge pull request #165 from julianklotz/master 
| |\ 
| | * e980526 Fix documentation Bug: CSS font attribute 
| |/ 
* | 4c4fe1a Ticker clean up and bug fixes. 
* | 6738d23 Documentation updates. 
* | 4fe4e97 Update docs and VERSIONS. 
* | c17aa05 Swapped append/prepend naming. 
* | 36dadb6 Fixed example in Graphics.append() docs. 
: | 
: |  [more snippage] 
: | 
* | 0960c56 Added Touch.disable() method. Fixed a very rare issue where Touch co 
* | c20ae9d Merge pull request #165 from julianklotz/master 
|\ \ 
| |/ 
|/| 
| * 26eb5dd Fix documentation Bug: CSS font attribute 
|/ 
* a21f210 Added SpriteSheetBuilder demo with MovieClip source. 
* 20d5dc7 Improvements to resolving mouse position on stage. Should now support 
:  [yet more snippage] 

你需要記住這裏是filter-branch，像git中的一切，不是更改任何現有的提交，它只有增加了新的提交。當篩選器進行一些更改時，filter-branch腳本會提交一個新的（不同）提交，與舊提交類似，但應用了該更改。因此，a21f210及以下版本不變，但26eb5dd與e980526不同：它們具有相同的樹和相同的父代ID（a21f210），但提交消息文本不同：一個以換行符結束，另一個不以。

一旦一些提交不同的是，每一個後代犯下-每一個承諾「後，」它的圖形，即中即承諾，必須也每個孩子是不同的，因爲每個提交包含ID（ s）的父母，作爲他們自己的ID的一部分。 （任何git對象的ID是該對象內容的加密校驗和，並且提交的內容包括父ID）。

如果/當您將這樣的過濾結果推送到像github這樣的共享存儲庫時， 每該共享存儲庫的用戶必須根據過濾重新調整其副本。假設6738d23 Documentation updates.是過濾之前在共享存儲庫中的內容，其他人都有6738d23，但是您（在您的推送中）創建97ffb07 Documentation updates.，其他人必須接受任何提交，它們的後代爲6738d23，並將它們重新綁定到97ffb07。這包括誰有4c4fe1a Ticker clean up and bug fixes.（這顯然是你）。然後他們必須停止使用6738d23並開始使用97ffb07。

如果上述假設是錯誤的，如果97ffb07是什麼在共享回購過濾前和6738d23是新的，那麼每個人都必須停止使用97ffb07版本，並開始使用6738d23一個來代替。

這個「每個人都必須停止使用A並開始使用B」的東西是什麼使得重寫歷史變得如此痛苦，並且在可能的情況下被避免。如果有人錯過了「停止使用A，開始使用B」指令，他們很可能會創建一個合併 - 就像您所做的那樣 - 將舊的「A及其所有父母」的歷史合併回來，使其看起來（並且）成爲所有新的「B及其所有父母」歷史的重複。

要解決此問題，您必須擺脫合併，即重新編寫歷史記錄。