大中型開發團隊如何不斷將更改推送到DVCS？

我工作的公司正試圖從集中式VCS StarTeam中脫身，並希望進一步改進。我不想僅僅選擇SVN，因爲它是「簡單的選擇」（與我們今天的做法最相似）。有人可以幫我理解一個大中型開發團隊如何每天更改大約150個文件可以在像Git或Mercurial這樣的DVCS上運行嗎？大中型開發團隊如何不斷將更改推送到DVCS？

我們：

50開發商有
15年的歷史
15 000份文件（主要是代碼/文）
大約150個單獨的文件簽入一個單一的存儲庫工作一天
由於我們獨特的語言要求和數據結構，每天需要從中心拉動變化

經過數天的研究和實驗，我瞭解Git和Hg的過程和工作流程。我不明白的是，需要對單個文件進行更改的大型團隊如何能夠在系統受到限制的情況下快速運行？

例如：我可能正在處理3種不同的事情，開發人員向我提出了一個小問題。我做了一點研究，做了必要的1行更改，並檢入文件。從我可以告訴的是，使用git我需要提交更改，隱藏所有其他更改，拉取，推送，應用存儲，處理任何合併，以便將最近提取的代碼隱藏起來。有沒有更好的辦法？

我讀過關於Facebook從Git轉換到Mercurial的文章。他們如何在40,000個文件庫中每天管理數千個簽入？我無法理解這將如何與DVCS的拉/推模型一起工作。我對這些系統的工作流程或功能缺少一些信息。也許他們不需要每天都拉/重新基地？

任何幫助表示讚賞。

來源

2015-12-03 Matt Erwin

「他們如何在一個40,000文件存儲庫上管理數以千計的簽入？」對於FB而言，它是「單一主線」+ [持續整合]（https://en.wikipedia.org/wiki/Continuous_integration）AFAICR –

http://www.wired.com/2015/09/google-2-billion- line-codeand-one-place/ –

我們很樂意實踐持續集成。不幸的是，我們被我們的語言和數據結構銬住了。抓取某些簽入的文件可能導致程序因需要重新格式化而停止工作。我們目前正在處理這個問題，因爲不需要整個回購單來檢查文件和每晚重建......我知道......並不理想。 –

我讀過關於Facebook從Git切換到Mercurial的文章。他們如何在40,000個文件庫中每天管理數千個簽入？我無法理解這將如何與DVCS的拉/推模型一起工作。我對這些系統的工作流程或功能缺少一些信息。也許他們不需要每天都拉/重新基地？

首先，Facebook並未以純粹的DVCS方式使用Mercurial。他們使用remotefilelog extension（他們自己寫的）只根據需求提取變更集（這是因爲Mercurial存儲歷史記錄以便歷史訪問可以大部分被本地化）。他們還爲其後端服務器提供use MySQL和memcached以提高可伸縮性。

對於rebase/merge瓶頸（當幾十個開發者需要將他們的工作同時集成到主分支中時），他們有a work in progress feature這樣做主要是服務器端;我注意到這個瓶頸部分是因爲（1）使用monorepo和（2）使用基於主幹的開發，這個問題並不是每個大型組織都會有的。

例如：我可能正在處理3種不同的事情，開發人員向我提出了一個小問題。我做了一點研究，做了必要的1行更改，並檢入文件。從我可以告訴的是，使用git我需要提交更改，隱藏所有其他更改，拉取，推送，應用存儲，處理任何合併，以便將最近提取的代碼隱藏起來。有沒有更好的辦法？

您可以使用新的Git worktree功能（或者，對於Mercurial，hg share）可以對同一個存儲庫進行多個簽出並獨立處理它們。市集和化石一直都能夠做到這一點; Fossil還具有自動同步功能，可以像SVN一樣進行操作（有注意事項），Bazaar一直能夠以準中心的方式工作，並提交直接到服務器。特別是，「每個存儲庫只有一次結賬」主要是歷史上的Git工件，而不是DVCS系統的代表（並且，正如我指出的那樣，更新的Git版本已經消失）。這就是說，你通常必須提交 - > pull - > merge或rebase - >推動對主分支的更改;這是一個折衷。分佈式模型允許您必須擁有簡單的本地版本控制，以便正在進行的工作在準備就緒之前不會直接進入主存儲庫。它也通常假設你的大部分工作都將發生在一個個人分支上，所以90％的時間只是承諾（偶爾會推）。

請注意，與集中式VCS相比，您不會有更多或更少的衝突;他們可能會出現在不同的點。

所有這一切說，如果你很高興與您當前的VCS，你不能從切換標識明確的好處，但它可能不值得改變你的VCS。切換VCS會帶來可觀的成本（重建您的回購，重新培訓您的開發人員，調整工作流程，調整週邊工具，出現意想不到的過渡問題），這些成本需要通過同等可衡量的收益來抵消，以使其值得。

來源

2015-12-03 11:32:47

1.對於Mercurial，hg share）具有多個簽出相同修訂版並獨立工作的版本「無法想象它的合理智能用例2.幾乎任何VCS都會比StarTeam更好，當然！！ –

1.我的意思是說「同一個儲存庫」（心理自動更正方向錯誤，我認爲）;將修復。 1A。即使是相同的版本，它仍然可能偶爾有用，以便能夠構建和測試當前正在進行更改的版本。 2.我完全不熟悉StarTeam，但我不會低估大型組織轉型的成本。 –

感謝您的回覆。我想以我的集中心態，我認爲推動總是需要在短期內遵循承諾。我喜歡代碼，提交，代碼提交的概念，然後當你的項目完成時，拉，推。或者在大型項目的情況下，推，合併。 –

我可能正在處理3種不同的事情，開發者向我提出了一個小問題。我做了一點研究，做了必要的1行更改，並檢入文件。從我可以告訴的是，使用git我需要提交更改，隱藏所有其他更改，拉取，推送，應用存儲，處理任何合併，以便將最近提取的代碼隱藏起來。有沒有更好的辦法？

是：因爲Git的2.5，你可以複製你的回購一次，但結賬多個倍。
如果您創建一個新分支，您可以在一個單獨的工作樹文件夾中創建它，從而保持當前的環境不受干擾。

請參閱「Multiple working directories with Git?」。

來源

2015-12-03 05:40:16 VonC

我希望，它會迅速火焰戰源被關閉，但...

我不想隨便挑SVN，因爲它是「容易的選擇」

不好意思，你想工作還是受苦？由於你的前任（不很清楚）的要求真正具有相當不錯的分支CVCS |合併可能比僞CVCS模式的任何DVCS更好的選擇（見What does SVN do better than Git? FE）

後的研究天試驗，我瞭解Git和Hg的過程和工作流程。

相當粗糙和淺薄的理解，BTW。即使是在Git中你有

「分行」（同時打了分支機構不在分支本身對其他DVCSes）
易變的歷史
DAG

例如：我可能正在處理3種不同的東西

VCS-agnostic方式的共同點（與水銀記住，混帳男生可能要它採用到GIT）

您與提交的一些（任何）量在每個

創建3個分支（「基於任務的發展」，「每任務分公司」的策略）

和開發人員過來對我提出一個小問題

提交您的當前工作目錄「原樣」
返回到本地歷史的分歧點（最後份額d變更？）
「做一個小小的研究，進行必要的1號線的變化，並在文件中檢查」（你）你在上面
最後chanseset庫的
開發商拉伸部可以退貨回來到斷點並繼續工作

來源

2015-12-03 05:55:55

大中型開發團隊如何不斷將更改推送到DVCS？

回答

相關問題