Perforce的Git用户？
在那里有很多“Perforce用户的Git”文档，但看起来却很less。
我以前只使用过Git，最近开始了一个我必须使用Perforce的工作，并且发现自己很多时候都很困惑。 我习惯Git的概念似乎根本不映射到Perforce。
有没有人有兴趣把使用Perforce的一些技巧提供给习惯了Git的人？
这个过去几个星期我一直在努力。 它仍在不断发展，但可能会有所帮助。 请注意我是Perforce员工。
为Git用户介绍Perforce
说从Git转移到Perforce，或者从Perforce转移到Git并不重要，这是一个很大的轻描淡写。 作为表面上做同样事情的两种工具，他们的做法不可能更加不同。 这篇简短的文章将帮助来自Git的新Perforce用户了解他们所处的新世界。
在我们潜入之前，有一个短暂的弯路。 如果你更喜欢Git，你可以使用Git和Perforce。 我们提供了一个名为Git Fusion的工具，可以生成与Perforce服务器保持同步的Git存储库。 Git和Perforce的人们可以在相同的代码中工作，他们大多不受同事select版本控制的影响。 Git融合13.3可从Perforce网站获得 。 它确实需要由Perforcepipe理员来安装，但是如果你安装它，你会发现它的存储库切片function作为一个Git用户可以非常方便。
如果你不能说服你的pipe理员安装Git Fusion，那么Git本身带有一个名为Git-P4的Perforce绑定，它允许你使用Git来改变和提交Perforce工作区中的文件。 有关这方面的更多信息，请访问： https ： //git.wiki.kernel.org/index.php/GitP4
还在？ 好，让我们来看看Perforce。
一些术语的差异来分类
在深入细节之前，我们需要简要介绍一下Git和Perforce之间的术语差异。
首先是结帐 。 在Git中，这是如何从指定的分支获取代码副本到您的工作区域。 在Perforce中，我们称之为来自命令行或来自我们的GUI P4V“获取最新版本”的同步 。 Perforce使用P4V的checkout或命令行中的p4 edit来表示您计划从版本控制系统更改文件。 在本文档的其余部分，我将使用Perforce的单词结帐。
第二个是Git 提交与Perforce 提交 。 你将在Git中提交的地方，你将在Perforce提交。 由于所有的操作都是针对共享的Perforce版本服务而发生的，Perforce没有与git push等效的function。 同样我们也没有pull 从上面的同步命令照顾为我们获取文件。 除非您select使用我们在下面简要描述的P4Sandbox工具，否则在Perforce中没有纯粹的本地提交的概念。
Perforce的关键概念
如果我将Perforce简化为两个关键概念，我将重点关注软件仓库和工作区。 Perforce软件仓库是存放在Perforce服务器中的文件的存储库。 Perforce服务器可以具有任意数量的软件仓库，每个软件仓库可以包含任意数量的文件。 通常你会听到Perforce的用户可以交换使用软件仓库和服务器，但是他们是不同的。 一个Perforce站点可能会select有多个服务器，但最常见的是所有文件都在一个服务器上。
Perforce工作区或客户端是系统中的一个对象，它将Perforce服务器中的一组文件映射到用户文件系统上的一个位置。 每个用户都有他们使用的每台机器的工作空间，并且经常用户将拥有同一台机器的多个工作空间。 工作区中最重要的部分是工作区映射或视图。
工作空间视图指定了应映射到本地计算机的软件仓库中的文件集。 这很重要，因为您不希望服务器上的所有文件都可用。 工作区视图允许您只select您关心的设置。 需要注意的是，工作空间可以映射来自多个仓库的内容，但只能映射来自一个服务器的内容。
为了比较Perforce和Git，在Git中，您可以select您感兴趣的Git仓库。每个仓库的范围通常很大，只包含相关的文件。 这样做的好处是没有configuration可以做你自己的一部分; 你做一个你关心的事情的git克隆，你就完成了。 如果只使用一个或两个存储库，这是非常好的。 使用Perforce，你需要花费一些时间来select你想要的代码。
许多Perforce商店使用可自动生成工作区视图的stream，或者使用脚本或模板工作区生成视图。 同样多的用户自己创build工作空间。 能够在一个工作区中映射多个模块的一个优点是您可以轻松修改多个代码模块， 您可以保证任何具有类似客户端视图的同步签入的人都将拥有正确状态下的所有代码。 这也可能导致过度依赖的代码， Git的强制分离可以带来更好的模块化。 值得庆幸的是，Perforce也可以支持严格的模块化。 这完全是您如何select使用该工具的问题。
为什么要工作区？
我认为，从Git来的，很容易感觉到整个工作空间的概念比它的价值更麻烦。 与克隆几个Git回购相比，这无疑是真实的。 工作空间的光辉，以及Perforce这些年来仍然在做生意的原因是，工作空间是为开发人员减less数百万个文件项目的一个很好的方法，同时还可以轻松地构build和发布，以将所有源代码从一个权威来源。 工作空间是Perforce可以扩展的主要原因之一。
工作区也很好，因为如果需要的话，软件仓库中的文件和用户机器上的布局的布局可能会有所不同。 许多公司组织他们的车厂来反映他们公司的组织结构，以便人们可以很容易地按业务单位或项目查找内容。 但是他们的构build系统可能不关心这个层次; 工作空间允许他们以任何对他们的工具有意义的方式来重新映射他们的仓库层次结构。 我也看到了那些正在使用非常不灵活的构build系统的公司所使用，这些系统要求代码处于非常特定的configuration中，这些configuration对人类来说是完全混淆的。 工作区允许这些公司拥有一个人类可导航的源代码层次结构，而他们的构build工具可以获得他们需要的结构。
Perforce中的工作区不仅用于映射用户想要使用的文件集，而且服务器还使用它们来精确跟踪用户已同步的每个文件的修订版本。 这允许系统在同步时向用户发送正确的一组文件，而不必扫描文件以查看哪些文件需要更新。 有了大量的数据，这可能是一个相当大的performance胜利。 这在审计规则非常严格的行业也很受欢迎。 Perforcepipe理员可以轻松跟踪和logging哪些开发者同步了哪些文件。
有关Perforce工作空间的全部function的更多信息，请阅读configurationP4 。
显式签出与隐式签出
用户从Git移动到Perforce的最大挑战之一是显式结账的概念。 如果你习惯于改变文件的Git / SVN / CVS工作stream程，然后告诉版本控制系统去寻找你所做的事情，那么这可能是一个非常痛苦的过渡。
好消息是，如果你愿意，你可以在Perforce中使用Git风格的工作stream程。 在Perforce中，您可以在工作区上设置“allwrite”选项。 这将告诉Perforce，所有的文件都应该被写入磁盘并设置可写位。 您可以在不明确告诉Perforce的情况下更改您希望的任何文件。 要让Perforce协调您所做的更改，您可以运行“p4 status”。 它将打开适当的添加，编辑和删除文件。 当以这种方式工作时，您将希望使用“p4 update”而不是“p4 sync”从服务器获取新的修订版; “p4 update”会在同步之前检查更改，因此如果尚未运行“p4 status”，则不会重新打开本地更改。
为什么显式结帐？
我经常收到一个问题：“你为什么要使用显式结账？” 它可以乍一看似乎是一个疯狂的devise决定，但明确的结账确实有一些强大的好处。
使用显式结帐的一个原因是它不需要扫描文件以进行内容更改。 虽然较小的项目计算每个文件的哈希以发现差异是相当便宜的，但是我们的许多用户在工作空间中有数百万个文件，并且/或者文件的大小为100兆（如果不是更大的话）。 在这些情况下计算所有的哈希值是非常耗时的。 显式检出让Perforce准确地知道需要使用哪些文件。 这种行为是Perforce在游戏，电影和硬件行业等大型文件行业如此受欢迎的原因之一。
另一个好处是显式检出提供了一种asynchronous通信的forms，可以让开发人员大致了解他们的同事正在工作或至less在哪里。 它可以让你知道，你可能想避免在某个领域工作，以避免不必要的冲突，或者它可以提醒你一个事实，即团队中的新开发人员已经走进了可能不需要的代码正在编辑。 我个人的经验是，我倾向于在Git中工作，或者使用Perforce工作来完成项目，在这个项目中我是唯一的贡献者或者是一个不经常的贡献者，当我和一个团队紧密合作的时候，我会明确的签出。 谢天谢地，select是你的。
显式检出也很好地与待处理更改列表的Perforce概念搭配使用。 等待更改列表是桶，你可以把你打开的文件来组织你的工作。 在Git中，您可能会使用不同的分支作为组织工作的桶。 分支是非常棒的，但有时在实际提交到服务器之前，能够将您的工作组织成多个命名的更改是非常好的。 使用Perforce模型可能将多个分支或多个项目映射到一个工作空间中，挂起的更改列表可以轻松地将单独的更改组织起来。
如果您使用IDE进行开发，例如Visual Studio或Eclipse，我强烈build议您为IDE安装一个Perforce插件。 大多数IDE插件会在您开始编辑文件时自动检出文件，从而使您无需自行完成检出。
Perforcereplace为Gitfunction
-
git stash==>p4 shelve - git本地分支==> Perforce架子或任务分支
-
git blame==>p4 annotate或Perforce Timelapse视图从GUI
工作断开
有两种select从Perforce版本控制服务中断开连接（这是Perforce服务器的特殊术语）。
1）使用P4Sandbox具有完整的本地版本控制和本地分支
2）根据您的需要编辑文件，并使用“p4状态”告诉Perforce您所做的事情
通过以上两个选项，您可以select在工作区中使用“allwrite”设置，以便不必解锁文件。 在此模式下工作时，您将需要使用“p4 update”命令来同步新文件，而不是“p4 sync”。 同步之前，“p4 update”将检查文件的更改。
Perforce快速入门
以下所有示例都将通过命令行进行。
1）configuration您的连接到Perforce
export P4USER=matt export P4CLIENT=demo-workspace export P4PORT=perforce:1666
您可以将这些设置保存在shellconfiguration文件中，使用p4 set将它们保存在Windows和OS X上，或者使用Perforceconfiguration文件。
1）创build一个工作区
p4 workspace # set your root to where your files should live: Root: /Users/matt/work # in the resulting editor change your view to map the depot files you care about //depot/main/... //demo-workspace/main/... //depot/dev/... //demo-workspace/dev/...
2）从服务器获取文件
cd /Users/matt/work p4 sync
3）签出你想要处理的文件并修改它
p4 edit main/foo; echo cake >> main/foo
4）提交给服务器
p4 submit -d "A trivial edit"
5） p4 help simple运行p4 help simple ，查看您将需要使用Perforce的基本命令。
可能没有很多这样的文档，因为Perforce是一个非常传统的版本控制系统（更接近CVS，Subversion等），通常被认为比现代分布式版本控制系统更简单。
试图将命令从一个映射到另一个不是正确的方法; 集中式和分布式版本控制系统的概念是不一样的。 相反，我将在Perforce中描述一个典型的工作stream程：
- 在要编辑的每个文件上运行
p4 edit编辑。 你需要告诉Perforce你正在编辑的文件。 如果您要添加新文件，请使用p4 add。 如果您要删除文件，请使用p4 delete。 - 改变你的代码。
- 运行
p4 change以创build更改集。 在这里，您可以创build变更的描述，也可以select从变更集中添加或删除文件。 如有必要，可以运行p4 change CHANGE_NUMBER以稍后编辑描述。 - 如果需要，您可以进行额外的代码更改。 如果您需要添加/编辑/删除其他文件，可以使用
p4 {add,edit,delete} -c CHANGE_NUMBER FILE。 - 运行
p4 sync从服务器中获取最新的更改。 - 运行
p4 resolve来解决来自同步的任何冲突。 - 当您准备好提交更改时，请运行
p4 submit -c CHANGE_NUMBER。
您可以使用p4 revert还p4 revert对文件的更改。
请注意，只要没有文件重叠，就可以同时处理多个变更集。 （Perforce客户端中的文件一次只能在一个变更集中打开。）如果您有小的，独立的更改，这有时可能会很方便。
如果您发现自己需要编辑已经在另一个变更集中打开的文件，则可以创build一个单独的Perforce客户端，或者您可以通过p4 shelve暂存现有的变更集。 （与git stash不同，shelving不会恢复本地树中的文件，因此您必须单独恢复它们。）
git和p4之间最大的区别就是它们使用不同的抽象单元。
- 在git中，抽象是补丁 （aka diff，又名变更集）。 git中的提交本质上是在提交的文件的之前和当前状态之间运行
diff的输出。 - 在执行中，抽象是文件 。 p4中的提交是当时提交中文件的全部内容。 这被组织成一个更改列表，但是修订本身是以每个文件为基础存储的，而更改列表只是简单地收集文件的不同修订版本。
其他一切都从这个差异中stream出来 在git中进行分支和合并是无痛的，因为从git抽象的angular度来看，每个文件可以通过按顺序应用一组补丁来完全重构，因此合并两个分支只需要在源分支上应用所有的补丁这些目标分支中没有以正确的顺序出现在目标分支中（假定两个分支上没有重叠的补丁）。
Perforce分支是不同的。 perforce中的分支操作会将文件从一个子文件夹复制到另一个子文件夹，然后用服务器上的元数据标记这些文件之间的链接。 要将文件从一个分支合并到另一个分支（perforce条件下的integration ），perforce将查看源分支“头部”处的文件的完整内容以及目标分支头部的文件的完整内容并在必要时合并使用共同的祖先。 它不能像git一样一个一个的应用补丁，这意味着手工合并更经常发生（并且往往更加痛苦）。
