Git fork - 重新綁定多個分支 - 保護程序共享提交

Question

我已經克隆了一個公共存儲庫。在我的本地庫我有一個分支結構類似這樣的地方字母代表提交：

[public tag: v1] - A - B - C [myBranch1] 
         \ 
         \- D [myBranch2] 

公共回購已移動，並且發佈了一個新的標籤「V2」。我想變基我的樹枝到新的版本，所以我所做的：

git rebase --onto v2 v1 myBranch1 
git rebase --onto v2 v1 myBranch2 

這似乎是工作，但它會創建提交A和B的內容相同，但不同的散列碼不同的副本：

[public tag: v2] - A' - B' - C' [myBranch1] 
       \ 
        \A''- B''- D' [myBranch2] 

我知道我可以做更復雜的東西，如：

git rebase --onto v2 v1 myBranch1 
git rebase --onto myBranch1 B myBranch2 

這應該給我，我想，但相當多的複雜的，結果特別是如果/當我創造更多additi ONAL分支機構。當我去捕獲提交hashcode時，它更容易出錯，並且必須跟蹤每個分支從哪個分支出發。

1）有沒有更好的方法來實現這個結果？我想你可能建議替代工作流程，但我很確定這是我想維護的分支/提交結構。

2）爲什麼做A'和A''的散列碼有區別？它們不是將相同差異/作者/時間戳應用於相同基線/內容的產品嗎？我意識到兩者是作爲兩個獨立的行動而產生的，但我會預料到這些行動是確定性的，因此「碰撞」（正確地）。

Answer 1

1）你可以通過使用merge-base的B的發現自動化：

git merge-base myBranch1 myBranch2 

會給你B

2）再次基於沒有真的動了原來的提交，這是相當複製它們，或實際上重播了每次提交造成的差異。重新發起的提交將總是有新的哈希值。

提交中的散列不僅是版本控制的整個文件樹的所有內容的校驗和，還包括父提交的散列的校驗和。所以，即使你會重現相同的文件樹（不太可能），你仍然會得到一個新的哈希，因爲你有一個不同的父。

Answer 2

[Klas Mellbourn擊敗了我;我的回答只是擴大了他在這一點上。]

爲什麼這是值得的，我已經看到了一些嘗試在「組或集體rebase」方法，允許這種事情。他們都需要某種方式來選擇首先分行的分支，然後再分配現在重新分行的其他「依賴」分行。

這些問題的答案是這樣的：

1. 沒有，但您可以自動完成這個。如何以及你可以自動完成是另一個問題。 :-)我見過的腳本並不像應該那樣聰明。（自動化系統應該拜倒在所有的分支機構，計算每個相應的合併基地，並做了一套最小的底墊/摘櫻桃的操作，記錄足夠的「初始狀態」打的時候，讓你做--abort或--continue需要手動解決百分點。這就需要延遲各個分支標籤的舉動了。）

2. A''都有不同的提交時間戳，VS A'（如果有完全相同提交的元數據和同一棵樹它的確會風相同的實際新提交）。由於Klas Mellbourn noted，一旦A''是不同的，一切都會如此。