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