可視化Network Graph Visualizer上的重新裝訂的叉

我正在使用git和github進行一個項目，該項目有幾個貢獻者，每個人都有自己的分支。可視化Network Graph Visualizer上的重新裝訂的叉

我最近對原有項目的master分支提交（merging一個分支叫chris-work），然後（作爲實驗）再根據叉的一個（使用How do I update a GitHub forked repository?細節）;這導致這樣的圖片，其中fork顯示爲黃色。

screenshot

如果你想看到現場圖，這是here。

新近重新基於fork沒有新變化，應該是（現在也是）完全一樣，從主體工程的master分支，但它出現在面前出來。

我敢肯定，這是可以預料的，但似乎從網絡圖我必須提交和merge一個（貌似）冗餘pull要求刪除fork。有人可以解釋更詳細的細節，並幫助我理解這種行爲？

來源

2014-01-07 cmhughes

GIT中提交的ID（SHA-1散列）的基礎上多條信息進行計算，包括

的提交的內容，
的提交父母，
提交消息，
提交的時間戳，和
可能有幾個我忘記了。

重要的是，許多位的數據和元數據會影響生成的散列。如果有任何不同（本例中爲時間戳和父母，至少），你會得到不同的散列，這意味着一個不同的提交。如果他們有不同的哈希，Git將永遠不會考慮兩個提交是平等的。

在這種情況下，您的重整分支的編號爲13c310f，而您的「真實master」編號的編號爲2d51e9e。

還請注意rebasing of published commits is strongly discouraged。

來源

2014-01-07 02:01:27 Chris

+1感謝您的提供，非常有幫助。那麼這是預期的行爲？或者我應該不同地使用'forks'？正如您在鏈接中看到的那樣，我們正在創建一個（非常大的）文檔，並且我們使用'git'＆'github'來幫助進行版本控制。我們應該簡單地使用分支而不是分叉？如果你有任何見解，我會非常感激。 – cmhughes

@cmhughes，是的，這是預期的行爲。在這種情況下，您可以使用叉子或分支;這取決於您是否想讓貢獻者提交對您的存儲庫的訪問權限。（如果您願意，您仍可以在一個存儲庫中的分支機構之間執行合併請求。）我認爲您真正關心的問題是重新分配。重新提交一個提交會一直改變它的哈希值，這就是爲什麼它[強烈建議重新推送提交]（http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing ）。 – Chris

感謝您的跟進，我非常感謝您的時間。閱讀你提供的鏈接（這可能值得添加到你的答案），聽起來像我會更好地使用'merge'而不是'rebase'？或者修復更復雜？再次感謝。 – cmhughes

可視化Network Graph Visualizer上的重新裝訂的叉

回答

相關問題