對於該使用(yòng) Git 或是 Perforce 來做(zuò)版本管理(lǐ)，有各式各樣的(de)論調；所有的(de)開發團隊都在尋找一個既能讓開發者滿意且能支援 DevOps 的(de)理(lǐ)想解決方案，所以決策者確實有許多(duō)需要考量的(de)因素。
在這裡我們將針對 Git 與 Perforce 的(de)差異點進行分(fēn)析，並且告訴您：如何一起使用(yòng)這兩項工具。
Git 與 Perforce 有何差異？
不同團隊有不同的(de)需求；Git 或許適合某一團隊，而 Perforce 也(yě)許正好符合另一個團隊的(de)版本控制需求。
Git 或許還不錯用(yòng)，特別適合一些人(rén)數較少的(de)團隊，或是純程式碼開發的(de)專案，或是開發時程較短的(de)產品，例如像是網頁開發。
然而 Perforce ─企業級的(de)版本管理(lǐ)，也(yě)是一個很好的(de)選項。尤其針對大(dà)型團隊，或是必須結合多(duō)種數位資產的(de)複雜專案，像是遊戲開發商，或是半導體公司。Perforce 解決方案能整合並管理(lǐ)所有數位資產––包括多(duō)媒體或設計圖等二進位 (binary) 檔案––並確保其安全性。
讓我們來檢視兩者幾個主要的(de)差異：
集中模式與分(fēn)散模式
Git 為分(fēn)散模式
使用(yòng)分(fēn)散模式的(de) Git，開發者可(kě)以下(xià)載程式碼（以及完整的(de)版本記錄）到自己的(de)電腦上，並在本地進行變更。在自己的(de)電腦上處理(lǐ)所有資料，可(kě)以讓本地提交、比對以及合併變得(de)更為迅速。
但是讓團隊成員各自擁有程式資料的(de)複本，必然需要對各自的(de)變更進行協調。問題是到底要以誰的(de)版本為準？公司可(kě)能也(yě)會有資料安全上的(de)考量；每個開發者在自己的(de)電腦上，都有專案完整的(de)資料，安全勢必難以管理(lǐ)。這正是為什(shén)麼越來越多(duō)的(de)團隊使用(yòng)集中模式的(de) Git。透過 pull 指令或是合併要求，來提交必要的(de)變更至專案的(de)主要分(fēn)支。這個過程必須由專屬的(de) Git 伺服器來完成，而非任一開發者的(de)電腦。
Git 權限在資料庫層級指派，因此有安全需求的(de)團隊通(tōng)常會將其專案拆分(fēn)成多(duō)個資料庫。這種作法可(kě)確保開發者隻能存取其所需的(de)資料，將使安全稽核輕鬆許多(duō)。然而這個方法卻也(yě)造成，團隊必需處理(lǐ)程式碼在多(duō)個資料庫間，互相依賴的(de)問題。
Perforce 為集中模式
HelixCore ––來自 Perforce 的(de)版本管理(lǐ)平台––具備集中模式。將所有資料儲存於一處，能確保開發者隨時都能取得(de)最新的(de)版本。無論開發者身處何地，皆能將所有的(de)變更上傳至中央伺服器。掌握專案的(de)主版本，便能在整個企業中建立單一資訊來源 ( Single Source of Truth ) ；由於團隊成員皆能便捷地看到進行中的(de)工作，所以也(yě)能增進溝通(tōng)的(de)效率。若是使用(yòng) Git，工作進度就隻能儲存在自己的(de)電腦裡。
集中模式不但能讓產品共同開發，與設計資料再利用(yòng)，變得(de)更為容易，同時還能確保其可(kě)稽核性及可(kě)追溯性。儘管 HelixCore 為集中式架構，仍可(kě)透過複本與代理(lǐ)伺服器等功能，安全地支援遠端的(de)開發者。這些功能確保大(dà)部分(fēn)的(de)資料處理(lǐ)都能在開發者本地端完成，進而大(dà)幅提升系統效能。
效能
提到效能，大(dà)家常對 Git 與 Perforce 的(de)比較結果感到意外。
Git 比較快(kuài)的(de)部分(fēn)
Git 在處理(lǐ)本地提交、比對及合併時，速度較快(kuài)。但當許多(duō)開發者執行 push 與 pull 的(de)時候，則會降低效能和(hé)生產力。
Perforce 比較快(kuài)的(de)部分(fēn)
HelixCore 是專為速度與規模所設計的(de)產品。一天能夠處理(lǐ)數百萬筆交易、管理(lǐ)數十億個檔案，總資料量以peta為單位。開發者可(kě)以在自己的(de)工作站，輕鬆快(kuài)速地確認自己是否擁有最新版本。此外，HelixCore 處理(lǐ)大(dà)型 binary 檔案時，會進行鎖定，以避免團隊成員間，產生變更衝突的(de)問題。
透過 Perforce 聯合架構，遠端團隊在進行大(dà)量複製／提取／程式建構時，也(yě)可(kě)享受本地端的(de)速度效能；可(kě)大(dà)幅縮短使用(yòng)傳統 Git 時，所需的(de)廣域網路等待時間。
處理(lǐ)大(dà)型檔案 / binary 檔案
大(dà)型檔案與 binary 構件皆為開發工作的(de)一環，這些有可(kě)能是程式建構的(de)產物(wù)，或是等待測試的(de)成品組件。對某些產業來說，像是遊戲開發公司，這些檔案是整個開發流程中不可(kě)或缺的(de)一部分(fēn)；您必須能夠結合美(měi)術人(rén)員與程式開發者的(de)工作成果，才能建造出完整的(de)產品。
Git 提供 LFS（大(dà)型檔案庫）
目前 Git 正嘗試以 Git LFS 來解決此類問題。但許多(duō)大(dà)型團隊必須將大(dà)量 binary 資產，儲存在如 Nexus 或 Artifactory 等構件庫工具中。這意味著您將不再擁有單一資訊來源，而且這些額外的(de)工具，絕對會使您的(de)建構管線更加複雜。
Perforce 將所有資料儲存在同一個資料庫裡
在HelixCore 上，構件、程式碼與其他(tā)設計資產，全部儲存在同一個資料庫裡；而這些構件與其原始資料，都能夠在同一變更清單上，簽入到資料庫裡。將所有資料集中儲存於一個中央伺服器，可(kě)使工作流程更加簡捷，管理(lǐ)員也(yě)無須管理(lǐ)額外的(de)軟體授權與系統整合。
分(fēn)支
Git 與 Perforce 都有輕量分(fēn)支的(de)功能，但兩者追蹤分(fēn)支的(de)方式不同。
Git 分(fēn)支
使用(yòng) Git 時，一旦分(fēn)支建立好，您便能在本地的(de)新分(fēn)支上作業。在您完成變更後、準備提交檔案時，您可(kě)以選擇 合併分(fēn)支 (merge) 或是 重整歷史 (rebase) 。然而在自己的(de)電腦上，合併分(fēn)支的(de)本地複本，並不等同於推送您的(de)變更至中央資料庫。
在您推送變更時，若有其他(tā)開發者在同一檔案中作業，很可(kě)能就會發生合併衝突；因此在合併前，必須要從伺服器提取最新變更。但是如果有多(duō)位開發者使用(yòng)Git 在同一專案上作業時，就會變得(de)極為麻煩且耗時。
如果您本來就必需處理(lǐ)，檔案在多(duō)個資料庫間，互相依賴的(de)問題，那麼更是雪(xuě)上加霜了(le)；因為現在您還得(de)想辦法，解決跨資料庫所產生的(de)合併衝突了(le)。這個問題，會隨著您的(de)團隊人(rén)數及資料量的(de)增加，越來越麻煩。
Perforce 分(fēn)支
HelixCore將分(fēn)支建立於檔案階層架構下(xià)。您的(de)團隊成員可(kě)簽出 (check out) 選定的(de)檔案進行編輯，並將工作成果提交 (submit) 送回資料庫。獨佔式簽出能讓開發者看到其他(tā)人(rén)正在進行的(de)工作，以避免提交成果時發生衝突。細至檔案層級的(de)權限設定，讓管理(lǐ)者能夠保護最重要的(de)檔案。
Perforce Streams 是我們在分(fēn)支與合併方法上的(de)創新，既能簡化(huà)工作區 (workspace) 的(de)設置，並能引導團隊進行分(fēn)支管理(lǐ)。開發者可(kě)輕鬆地在 stream（分(fēn)支）間切換，並檢視變更傳播的(de)方向。雖然提交變更至主 stream 時，您還是可(kě)能會遇到衝突，但是這些衝突會變得(de)十分(fēn)容易管理(lǐ)。HelixCore 的(de)優勢在於，不但能夠輕鬆地檢視工作進度，而且能夠預測潛在的(de)合併衝突風險。
再者，HelixCore 的(de)管理(lǐ)規模，讓開發者能夠一次提交，包含多(duō)個元件的(de)大(dà)型變更清單。此舉可(kě)大(dà)幅降低，因為檔案互相依賴所產生的(de)問題，也(yě)不會有使用(yòng) Git 時，跨資料庫依賴的(de)問題；唯有如此，才能輕鬆地追蹤管理(lǐ)所有的(de)變更。
Git 的(de)不足之處
Git 獲得(de)許多(duō)團隊青睞，並非沒有道理(lǐ)。
如上述說明(míng)，它解決了(le)最基本的(de)版本控制問題。讓開發者能夠共同開發程式碼，並避免重複作業的(de)浪費。
其本地作業也(yě)相當快(kuài)速。Git 經常是開發者在大(dà)學時代，第一個接觸的(de)版本控制系統，所以大(dà)部分(fēn)開發者都知道常用(yòng)的(de) Git 指令，如 clone, commit, push 等。除此之外，它還是免費的(de)！
GitHub、GitLab 與 Atlassian，對企業中的(de)軟體開發團隊來說，並不一定合用(yòng)；例如 Git 的(de)架構，已證實在企業環境下(xià)十分(fēn)難以擴充。
使用(yòng) Perforce 的(de)時機 ( HelixCore )
Perforce 是最佳的(de)版本控制系統選擇，如果您有…
 |
龐大(dà)的(de)程式庫。 |
|---|---|
|
非程式碼資產，例如 binary 檔案或圖像檔。 |
|
檔案互相依賴，尤其是跨元件依賴的(de)類型。 |
|
廣泛的(de)設計資料再利用(yòng)，例如構件 (artifact)。 |
|
龐大(dà)且分(fēn)散在不同地點的(de)團隊。 |
因為我們的(de)版本控制系統，是專門為擁有龐大(dà)資料庫，和(hé)複雜開發環境的(de)大(dà)型團隊所設計；這也(yě)正是 Perforce 能夠在此勝出的(de)原因！
所以到底該用(yòng) Git 還是 Perforce？答(dá)案是…不需選擇
企業需要 Perforce 所提供的(de)可(kě)擴展性，與其架構設計所帶來的(de)效益。現在，您不但可(kě)享受這些效益，還能同時使用(yòng) Git。
此難題的(de)最佳解答(dá)並非決定該使用(yòng) Perforce 或 Git，而是利用(yòng) Helix4Git，來整合 Perforce 和(hé) Git。
Helix4Git 能儲存 Git 資料庫，並具備 Perforce HelixCore 伺服器的(de)速度與可(kě)靠性。此項獨占業界鰲頭的(de)解決方案，定能支援貴公司的(de) DevOps 發展。
為 Git 使用(yòng)者設計的(de) Perforce：Helix4Git
開發者仍可(kě)繼續使用(yòng)如 merge 或 rebase 等這些 Git 指令，或是建立子模組等，應有盡有；因為他(tā)們能同時存取這兩個系統，所以不需改變現有工作流程或環境的(de)設定。
事實上，即便您的(de)專案已經開發到一半，仍可(kě)立馬加裝 Helix4Git；就是這麼地輕鬆無縫接軌。您可(kě)將 Git 資料庫直接儲存於 HelixCore，當然它也(yě)同樣支援Git LFS 構件 (artifacts)。
一個集中控管的(de)，單一資訊來源，才能夠最佳化(huà)持續整合 / 持續交付 (CI/CD) 的(de)實踐。
Helix4Git 讓 Git 更快(kuài) — 速度加快(kuài) 80%，節省 18% 儲存空間
這意味著團隊能夠更快(kuài)得(de)到所需的(de)回饋。開發者、發行管理(lǐ)者，以及 CI/CD 團隊，都將能擁有更多(duō)自己的(de)時間。
歡迎關注 Graser 社群，即時掌握最新技術應用(yòng)資訊
