# Migrating from Perforce Helix > 原文：[https://docs.gitlab.com/ee/user/project/import/perforce.html](https://docs.gitlab.com/ee/user/project/import/perforce.html) * [Perforce vs Git](#perforce-vs-git) * [Why migrate](#why-migrate) * [How to migrate](#how-to-migrate) # Migrating from Perforce Helix[](#migrating-from-perforce-helix "Permalink") [Perforce Helix](https://www.perforce.com/)提供了一套工具，其中還包括類似于 Git 的集中式專有版本控制系統. ## Perforce vs Git[](#perforce-vs-git "Permalink") 以下列表說明了 Perforce Helix 和 Git 之間的主要區別： 1. 通常，最大的區別是與 Git 的輕量級分支相比，Perforce 分支是重量級的. 當您在 Perforce 中創建分支時，它會在其專有數據庫中為分支中的每個文件創建一個集成記錄，無論實際更改了多少. 而 Git 是采用不同的體系結構實現的，因此，單個 SHA 可以充當更改后整個存儲庫狀態的指針，這使得分支非常容易. 這就是功能分支工作流如此容易被 Git 采納的原因. 2. 而且，在 Git 中，分支之間的上下文切換要容易得多. 如果您的經理說"您需要停止使用該新功能并修復此安全漏洞"，那么您可以在 Git 中輕松地做到這一點. 3. 在本地計算機上擁有項目及其歷史的完整副本意味著每筆交易都非常快，而 Git 則提供了該副本. 您可以單獨進行分支/合并和試驗，然后在與所有人共享新的有趣內容之前清理混亂. 4. Git 還使代碼審核變得簡單，因為您可以共享更改而無需將更改合并到主版本中，而 Perforce 必須在服務器上實現 Shelving 功能，以便其他人可以在合并之前查看更改. ## Why migrate[](#why-migrate "Permalink") 從用戶和管理員的角度來看，Perforce Helix 可能難以管理. 遷移到 Git / GitLab 有： * **沒有許可費用** ，Git 是 GPL，而 Perforce Helix 是專有的. * **學習曲線更短** ，Git 有一個龐大的社區和大量的入門指南. * **與現代工具集成** ，遷移到 Git 和 GitLab，您可以擁有一個開源的端到端軟件開發平臺，該平臺具有內置的版本控制，問題跟蹤，代碼審查，CI / CD 等. ## How to migrate[](#how-to-migrate "Permalink") Git 包含一個內置機制（ `git p4` ），用于從 Perforce 中提取代碼并將其從 Git 提交回 Perforce. 以下是一些入門指南： * [`git-p4` manual page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-p4.html) * [`git-p4` example usage](https://git.wiki.kernel.org/index.php/Git-p4_Usage) * [Git book migration guide](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git#_perforce_import) 請注意， `git p4`和`git filter-branch`在創建小型高效 Git 包文件方面不是很好. 因此，在第一次將存儲庫發送到 GitLab 服務器之前，花一些時間和 CPU 適當地重新打包存儲庫可能是個好主意. 請參閱[此 StackOverflow 問題](https://stackoverflow.com/questions/28720151/git-gc-aggressive-vs-git-repack/) .