有很多“Git for Perforce用户”文档，但看起来很少相反。
我之前只使用过Git，最近开始了一项工作，我必须经常使用Perforce，并且发现自己很多时候都很困惑。我从Git习惯的概念似乎根本没有映射到Perforce。
是否有人有兴趣为一些习惯Git的人使用Perforce提供一些技巧？
答案 0 :(得分：292)
这是过去几周我一直在努力的事情。它仍在不断发展，但它可能会有所帮助。请注意我是Perforce员工。
要说从Git转移到Perforce或从Perforce转移到Git是非常重要的，这是一种轻描淡写的说法。作为表面上做同样事情的两种工具，他们的方法不可能更加不同。这篇简短的文章将尝试帮助来自Git的新Perforce用户了解他们所处的新世界。
在我们潜入之前进行一次简短的绕行;如果你更喜欢Git，你可以很好地使用Git和Perforce。我们提供了一个名为Git Fusion的工具，它可以生成与Perforce服务器保持同步的Git存储库。 Git和Perforce的人们可以在相同的代码上和谐共处，大多数情况下不会受到同事选择版本控制的影响。 Git Fusions 13.3可从Perforce web site获得。它确实需要由Perforce管理员安装，但是如果你安装它，你会发现它的存储库切片功能作为Git用户非常方便。
如果您无法说服您的管理员安装Git Fusion，Git本身会附带一个名为Git-P4的Perforce绑定，允许您使用Git在Perforce工作区中更改和提交文件。有关这方面的更多信息，请访问：https://git.wiki.kernel.org/index.php/GitP4
还在吗？好的，让我们来看看Perforce。
在我们详细介绍之前，我们需要简要介绍一下Git和Perforce之间的几个术语差异。
第一个是结帐。在Git中，您可以获得从给定分支到您工作区域的代码副本。在Perforce中，我们从命令行或从我们的GUI P4V＆＃34;获取最新版本＆＃34;中将其称为 sync 。 Perforce使用P4V中的 checkout 或命令行中的p4 edit来表示您计划从版本控制系统更改文件。在本文档的其余部分中，我将使用Perforce意义上的结帐。
第二个是Git 提交与Perforce 提交。如果你在Git中提交，你将在Perforce中提交。由于所有操作都是针对共享的Perforce版本控制服务而发生的，因此Perforce没有git push的等价物。同样，我们没有pull;上面的sync命令负责为我们获取文件。 Perforce中没有纯本地提交的概念，除非您选择使用我们下面简要介绍的P4Sandbox工具。
如果我要将Perforce简化为两个关键概念，我将专注于软件仓库和工作区。 Perforce depot是存储在Perforce服务器中的文件的存储库。 Perforce服务器可以包含任意数量的depot，每个depot可以包含任意数量的文件。您经常会听到Perforce用户可以互换使用软件仓库和服务器，但它们是不同的。 Perforce站点可以选择拥有多个服务器，但最常见的是所有文件都在一个服务器中。
Perforce工作空间或客户端是系统中的一个对象，它将Perforce服务器中的一组文件映射到用户文件系统上的某个位置。每个用户都为他们使用的每台机器都有一个工作区，并且用户通常会为同一台机器拥有多个工作区。工作空间最重要的部分是工作空间映射或视图。
工作空间视图指定应该映射到本地计算机的库中的文件集。这很重要，因为您很可能不希望服务器上的所有文件都可用。工作区视图允许您仅选择您关注的集合。值得注意的是，工作区可以映射多个软件仓库中的内容，但只能映射来自一个服务器的内容。
在这方面要比较Perforce和Git，用Git选择你感兴趣的Git repos集。每个repo通常都是严格限定的，只包含相关的文件。这样做的好处是您无需进行任何配置;你做了你关心的事情的git克隆，你已经完成了。如果您只使用一个或两个存储库，这一点尤其好。使用Perforce，您需要花一点时间选择和选择所需的代码。
许多Perforce商店使用可以自动生成工作区视图的流，或者使用脚本或模板工作区生成视图。同样多的人让他们的用户自己生成他们的工作区。能够在一个工作空间中映射多个模块的一个优点是，您可以在一个签入中轻松修改多个代码模块;您可以保证具有类似客户端视图的任何人与您的签入同步将使所有代码处于正确状态。这也可能导致过度依赖的代码;强制分离Git可以带来更好的模块化。值得庆幸的是Perforce也可以支持严格的模块化。这是您选择使用该工具的所有问题。
我认为从Git来的时候，很容易感觉整个工作空间概念比它的价值更麻烦。与克隆一些Git repos相比，这无疑是正确的。工作空间大放异彩，以及Perforce在这么多年后仍处于业务中的原因是，工作空间是为开发人员削减数百万个文件项目的绝佳方式，同时仍然可以轻松地构建和发布所有来源一个权威来源。工作区是Perforce可以扩展的关键原因之一。
工作区也很不错，因为软件仓库中的文件布局和用户机器上的布局可能会有所不同。许多公司组织他们的仓库来反映他们公司的组织，以便人们可以轻松地按业务单位或项目查找内容。然而，他们的构建系统对这种层次结构并不在乎;工作区允许他们以任何对他们的工具有意义的方式重新映射他们的软件仓库层次结构。我也看到过使用非常不灵活的构建系统的公司所使用的，这些构建系统要求代码处于非常特殊的配置中，这些配置对人类来说完全是混乱的。工作区允许这些公司拥有一个人类可导航的源层次结构，同时他们的构建工具可以获得所需的结构。
Perforce中的工作空间不仅用于映射用户想要使用的文件集，而且服务器还使用它们来准确跟踪用户已同步的每个文件的修订版本。这允许系统在同步时向用户发送正确的文件集，而不必扫描文件以查看需要更新的文件。对于大量数据，这可以获得相当大的性能。这在具有非常严格的审计规则的行业中也非常受欢迎; Perforce管理员可以轻松跟踪和记录哪些开发人员同步了哪些文件。
有关Perforce工作区全部功能的更多信息，请阅读Configuring P4。
用户从Git迁移到Perforce的最大挑战之一是明确结账的概念。如果您习惯于更改文件的Git / SVN / CVS工作流程，然后告诉版本控制系统查找您所做的事情，那么这可能是一个非常痛苦的过渡。
好消息是，如果您这样选择，您可以在Perforce中使用Git风格的工作流程。在Perforce中，您可以设置＆＃34; allwrite＆＃34;工作区上的选项。这将告诉Perforce所有文件都应写入磁盘并设置可写位。然后，您可以在不明确告知Perforce的情况下更改所需的任何文件。要让Perforce协调您所做的更改，您可以运行＆＃34; p4 status＆＃34;。它将根据需要打开文件以进行添加，编辑和删除。以这种方式工作时，您将需要使用＆＃34; p4 update＆＃34;而不是＆＃34; p4 sync＆＃34;从服务器获取新版本; ＆＃34; p4更新＆＃34;在同步之前检查更改，这样就不会破坏您的本地更改，如果您还没有运行＆＃34; p4 status＆＃34;爱好。
我经常收到的一个问题是＆＃34;为什么你会想要使用明确的结账？＆＃34;乍一看似乎是一个疯狂的设计决定，但明确的结账确实有一些强大的好处。
使用显式签出的一个原因是它不需要扫描文件以进行内容更改。虽然较小的项目计算每个文件的哈希值以查找差异相当便宜，但我们的许多用户在工作空间中拥有数百万个文件和/或文件大小为100兆字节（如果不是更大）。在这些情况下计算所有哈希值非常耗时。显式检出让Perforce确切地知道它需要使用哪些文件。这种行为是Perforce在游戏，电影和硬件行业等大型文件行业如此受欢迎的原因之一。
另一个好处是显式检出提供了一种异步通信形式，可以让开发人员普遍了解他们的同事正在做什么，或者至少在哪里。它可以告诉您，您可能希望避免在某个区域工作以避免不必要的冲突，或者它可以提醒您团队中的新开发人员已经徘徊在代码中的事实可能他们不会需要编辑。我个人的经验是，我倾向于在Git中工作，或者使用Perforce在我不是唯一的贡献者或不经常的贡献者的项目上使用Perforce，并且在我与团队紧密合作时明确结账。谢天谢地，选择权归你所有。
明确的结帐也可以很好地与Perforce的待定更改列表概念相匹配。待更改列表是您可以将打开的文件放入以组织工作的存储桶。在Git中，您可能会使用不同的分支作为组合工作的桶。分支很棒，但有时能够在实际提交到服务器之前将工作组织成多个命名更改是很好的。使用可能将多个分支或多个项目映射到一个工作区的Perforce模型，待定的更改列表可以轻松地保持组织的单独更改。
如果您使用IDE进行开发，例如Visual Studio或Eclipse，我强烈建议您为IDE安装Perforce插件。当您开始编辑文件时，大多数IDE插件都会自动签出文件，让您不必自己进行结帐。
git stash ==＆gt; p4 shelve git blame ==＆gt;来自GUI的p4 annotate或 Perforce Timelapse View 有两种方法可以与Perforce版本控制服务断开连接（这是我们对Perforce服务器的精彩术语）。
1）使用P4Sandbox进行完整的本地版本控制和本地分支
2）根据需要编辑文件并使用＆＃39; p4 status＆＃39;告诉Perforce你做了什么
使用上述两个选项，您可以选择使用＆＃34; allwrite＆＃34;在工作区中进行设置，这样您就不必解锁文件。在此模式下工作时，您将需要使用＆＃34; p4更新＆＃34;命令同步新文件而不是＆＃34; p4 sync＆＃34;。 ＆＃34; p4更新＆＃34;将在同步文件之前检查文件是否有变化。
以下所有示例都将通过命令行。
1）配置与Perforce的连接
export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666
您可以将这些设置粘贴在shell配置文件中，使用p4 set将它们保存在Windows和OS X上，或者使用Perforce配置文件。
1）创建工作区
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以查看使用Perforce所需的基本命令。
答案 1 :(得分：20)
git和p4之间的最大区别在于它们使用不同的抽象单元，而现有的答案都没有解决。
diff的输出。其他一切都来自这种差异。 git中的分支和合并是无痛的，因为从git的抽象的角度来看，每个文件都可以通过按顺序应用一组补丁来完全重建，因此要合并两个分支，你只需要在源分支上应用所有补丁目标分支中没有以正确的顺序出现在目标分支中（假设两个分支上没有重叠的补丁）。
Perforce分支是不同的。 perforce中的分支操作会将文件从一个子文件夹复制到另一个子文件夹，然后使用服务器上的元数据标记文件之间的链接。要将文件从一个分支合并到另一个分支（per integration，perforce术语），perforce将查看源分支上“head”处的文件的完整内容和< em>目标分支头部的文件的完整内容，如果需要，使用共同的祖先进行合并。它无法像git can一样逐个应用补丁，这意味着手动合并更频繁地发生（并且往往更加痛苦）。
答案 2 :(得分：18)
可能没有很多此类文档，因为Perforce是一个相当传统的版本控制系统（更接近CVS，Subversion等），并且通常被认为不如现代分布式版本控制系统复杂。
尝试将命令从一个映射到另一个不是正确的方法;集中式与分布式版本控制系统的概念并不相同。相反，我将描述Perforce中的典型工作流程：
p4 edit。您需要告诉Perforce您正在编辑哪些文件。如果您要添加新文件，请使用p4 add。如果您要删除文件，请使用p4 delete。p4 change以创建变更集。您可以在此处创建更改说明，也可以选择在变更集中添加或删除文件。如有必要，您可以运行p4 change CHANGE_NUMBER以稍后编辑说明。p4 {add,edit,delete} -c CHANGE_NUMBER FILE。p4 sync以从服务器提取最新更改。p4 resolve以解决同步中的任何冲突。p4 submit -c CHANGE_NUMBER。您可以使用p4 revert还原对文件的更改。
请注意，只要没有任何文件重叠，您就可以同时处理多个更改集。 （Perforce客户端中的文件一次只能在一个变更集中打开。）如果您进行小的独立更改，这有时会很方便。
如果您发现自己需要编辑已在另一个变更集中打开的文件，则可以创建单独的Perforce客户端，也可以通过p4 shelve隐藏现有的变更集。 （与git stash不同，搁置不会还原本地树中的文件，因此您必须单独还原它们。）