1
對於某些情況，我正在開發一個分佈式程序，需要與多個合作者實時進行版本管理和衝突解決，並且我正在考慮在底層使用Git（特別是https://github.com/creationix/js-git）。每個用戶都有他們自己的參考，但是會有全球歷史（很像GitHub所做的）。但與GitHub不同的是，所有用戶的分支都應該是平等的，並且pull請求不是單向進入上游分支。Git：如果A從B合併，並且B獨立地從A合併而沒有衝突，他們是否可以做出相同的提交？
我正在考慮一個方案，其中兩個用戶，剛剛取得[犯下如下圖所示爲A和B]自己下線的變化，選擇將分別利用其合作者的發展分支在同一時間拉。假設合併是使用相同版本的Git完成的，沒有發現與遠程衝突類似的東西，這兩個合併最終會以同一棵樹結束，但是（據我所知），因爲執行合併提交的用戶有不同的名稱，合併提交C和C'將有不同的哈希（因此是不同的）。
...A---C
/ \/
O /
\ /\
...B---C'
的事情是，如果沒有衝突，在C和C」是相同的，我真的很想樹木和家長，使他們看起來是一樣的承諾，如果有的話只允許在未來更容易快速轉發，並允許更清晰的交付圖表演示。
我看到它，如果姓名，電子郵件地址，並提交時間被自動設定爲在合併相同的提交（即在最新的合併通過[email protected]提交父母的時間）的方式，那麼C和C'會一樣嗎？所以這相當於從權威的上游來源拉動C/C'？我應該知道這種方法有什麼陷阱或危險嗎？或者，Git可以自動處理一些我不知道的功能嗎？
您認爲兩個人在*完全相同的時間相互拉扯的可能性有多大？在其他情況下，B只會從A中取出C並快速前進，因此C'將永遠不會創建，並且您的問題不存在。 – Chronial
在這種特殊情況下，由於在GUI上進行鼠標點擊或拖放操作，可能會立即進行提交，因此在國際協作者的網絡延遲的第二個左右的時間內發生這種情況是完全有理由的。 – btown
我明白那個部分，但那仍然需要那些用戶在同一秒鐘點擊按鈕。這可能會每年發生一次，如果它確實會得到一個不必要的合併提交。你可以考慮編寫大量的代碼來防止這種情況發生。顯然Linus Torwalds認爲它沒有;）。 – Chronial