git Git用户的Perforce？

Perforce for Git users?

提问by Brennan Vincent

There is a lot of "Git for Perforce users" documentation out there, but seemingly very little of the opposite.

那里有很多“Git for Perforce 用户”文档，但似乎很少有相反的内容。

I have only used Git previously and recently started a job where I have to use Perforce a lot, and find myself getting very confused a lot of the time. The concepts I'm used to from Git seem not to map to Perforce at all.

我以前只使用过 Git，最近开始了一份工作，我必须经常使用 Perforce，并且发现自己很多时候都非常困惑。我从 Git 中习惯的概念似乎根本无法映射到 Perforce。

Is anyone interested in putting together a few tips for using Perforce for someone who is used to Git?

有没有人有兴趣为习惯 Git 的人整理一些使用 Perforce 的技巧？

回答by Matt

This something I've been working on over the past couple weeks on and off. It's still evolving, but it may be helpful. Please note I'm a Perforce employee.

这是我在过去几周断断续续地进行的工作。它仍在发展中，但可能会有所帮助。请注意，我是 Perforce 的员工。

An intro to Perforce for Git users

面向 Git 用户的 Perforce 简介

To say that moving from Git to Perforce or from Perforce to Git is non-trivial is a grand understatement. For being two tools that ostensibly do the same thing, their approach could not be more different. This brief write-up will try to help new Perforce users coming from Git understand the new world they are in.

要说从 Git 迁移到 Perforce 或从 Perforce 迁移到 Git 并非易事，这是一种轻描淡写的说法。作为表面上做同一件事的两个工具，他们的方法非常不同。这篇简短的文章将尝试帮助来自 Git 的新 Perforce 用户了解他们所处的新世界。

One brief detour before we dive in; if you prefer Git you can use Git with Perforce quite well. We provide a tool called Git Fusion that generates Git repositories that are kept in sync with the Perforce server. Git and Perforce people can live in harmony working on the same code, mostly unaffected by their co-workers choice of version control. Git Fusions 13.3 is available from the Perforce web site. It does need to be installed by the Perforce administrator, but if you install it you will find that its repository slicing feature can be quite handy as a Git user.

在我们潜入之前绕道一小段路；如果你更喜欢 Git，你可以很好地将 Git 与 Perforce 结合使用。我们提供了一个名为 Git Fusion 的工具，它生成与 Perforce 服务器保持同步的 Git 存储库。Git 和 Perforce 的人可以在相同的代码上和谐相处，几乎不受他们的同事选择的版本控制的影响。Git Fusions 13.3 可从Perforce 网站获得。它确实需要由 Perforce 管理员安装，但是如果您安装它，您会发现它的存储库切片功能对于 Git 用户来说非常方便。

If you can't convince your admin to install Git Fusion, Git itself comes with a Perforce binding called Git-P4 that allows you to use Git to change and submit files in a Perforce workspace. More information on that can be found at: https://git.wiki.kernel.org/index.php/GitP4

如果您无法说服您的管理员安装 Git Fusion，Git 本身带有一个名为 Git-P4 的 Perforce 绑定，它允许您使用 Git 在 Perforce 工作区中更改和提交文件。有关更多信息，请访问：https: //git.wiki.kernel.org/index.php/GitP4

Still here? Good, let's look at Perforce.

还在？好的，让我们看看 Perforce。

Some Terminology Differences to Sort Out

一些术语差异需要整理

Before we get into the details we need to briefly cover a couple terminology differences between Git and Perforce.

在我们进入细节之前，我们需要简要介绍一下 Git 和 Perforce 之间的几个术语差异。

The first is checkout. In Git this is how you get a copy of the code from a given branch into your working area. In Perforce we call this a syncfrom the command line or from our GUI P4V "Get Latest Revision". Perforce uses the word checkoutfrom P4V or p4 editfrom the command line to mean that you plan to change a file from the version control system. In the rest of this document, I'll be using checkout in the Perforce sense of the word.

首先是结帐。在 Git 中，这是从给定分支获取代码副本到工作区的方式。在 Perforce 中，我们将其从命令行或从我们的 GUI P4V“获取最新版本”中称为同步。Perforce 使用来自 P4V 或命令行的checkout一词p4 edit表示您计划从版本控制系统更改文件。在本文档的其余部分，我将使用 Perforce 意义上的 checkout。

The second is Git commitversus Perforce submit. Where you would commit in Git you will submit in Perforce. Being that all operations happen against the shared Perforce versioning service, Perforce doesn't have an equivalent for git push. Likewise we don't have a pull; the sync command from above takes care of getting files for us. There is no concept of a pure local submit in Perforce unless you choose to use our P4Sandbox tool described briefly below.

第二个是 Git提交与 Perforce提交。你在 Git 中提交的地方，你将在 Perforce 中提交。由于所有操作都是针对共享的 Perforce 版本控制服务进行的，因此 Perforce 没有对应的git push. 同样，我们没有pull; 上面的同步命令负责为我们获取文件。Perforce 中没有纯本地提交的概念，除非您选择使用我们下面简要介绍的 P4Sandbox 工具。

Key Concepts in Perforce

Perforce 中的关键概念

If I were to simplify Perforce to two key concepts I would focus on the depot and the workspace. A Perforce depot is a repository of files that lives in a Perforce server. A Perforce server can have any number of depots and each depot can contain any number of files. Frequently you will hear Perforce users use depot and server interchangeably, but they are different. A Perforce site may choose to have multiple servers, but most commonly all files are in one server.

如果我要将 Perforce 简化为两个关键概念，我会关注仓库和工作区。Perforce depot 是位于 Perforce 服务器中的文件存储库。Perforce 服务器可以有任意数量的软件仓库，每个软件仓库可以包含任意数量的文件。您经常会听到 Perforce 用户交替使用 depot 和 server，但它们是不同的。Perforce 站点可以选择有多个服务器，但最常见的是所有文件都在一个服务器中。

A Perforce workspace or client is an object in the system that maps a set of files in the Perforce server to a location on a user's file system. Every user has a workspace for each machine they use, and frequently users will have more than one workspace for the same machine. The most important part of a workspace is the workspace mapping or view.

Perforce 工作区或客户端是系统中的一个对象，它将 Perforce 服务器中的一组文件映射到用户文件系统上的某个位置。每个用户对于他们使用的每台机器都有一个工作区，而且用户经常会为同一台机器拥有多个工作区。工作区最重要的部分是工作区映射或视图。

The workspace view specifies the set of files in the depot that should be mapped to the local machine. This is important because there is a good chance that you do not want all of the files that are available on the server. A workspace view lets you select just the set that you care about. It's important to note that a workspace can map content from multiple depots, but can only map content from one server.

工作区视图指定应映射到本地计算机的库中的文件集。这很重要，因为您很可能不想要服务器上可用的所有文件。工作区视图可让您仅选择您关心的集合。需要注意的是，工作区可以映射来自多个仓库的内容，但只能映射来自一台服务器的内容。

To compare Perforce to Git in this regard, with Git you pick and choose the set of Git repos that you are interested in. Each repo is generally tightly scoped to contain just related files. The advantage of this is there is no configuration to do on your part; you do a git clone of the things you care about and you're done. This is especially nice if you only work with one or two repositories. With Perforce you need to spend a bit of time picking and choosing the bits of code you want.

为了在这方面将 Perforce 与 Git 进行比较，您可以使用 Git 挑选您感兴趣的一组 Git 存储库。每个存储库通常都被严格限定为仅包含相关文件。这样做的好处是您无需进行任何配置；你对你关心的事情做一个 git clone，你就完成了。如果您只使用一两个存储库，这尤其好。使用 Perforce，您需要花一些时间来挑选和选择所需的代码位。

Many Perforce shops use streams which can automatically generate a workspace view, or they generate the view using scripts or template workspaces. Equally many leave their users to generate their workspaces themselves. One advantage of being able to map a number of modules in one workspace is you can easily modify multiple code modules in one checkin; you can be guaranteed that anyone with a similar client view who syncs to your checkin will have all the code in the correct state. This can also lead to overly dependent code though; the forced separation of Git can lead to better modularity. Thankfully Perforce can also support strict modularity as well. It's all a question of how you choose to use the tool.

许多 Perforce 商店使用可以自动生成工作区视图的流，或者他们使用脚本或模板工作区生成视图。同样，许多让用户自己生成工作区。能够在一个工作区中映射多个模块的优势之一是您可以在一次签入中轻松修改多个代码模块；您可以保证任何具有类似客户端视图并同步到您的签入的人都将拥有处于正确状态的所有代码。不过，这也可能导致过度依赖代码；Git 的强制分离可以带来更好的模块化。幸运的是，Perforce 也可以支持严格的模块化。这完全是您选择如何使用该工具的问题。

Why Workspaces?

为什么是工作区？

I think in coming from Git it is easy to feel like the whole workspace concept is way more trouble than it is worth. Compared to cloning a few Git repos this is undoubtably true. Where workspaces shine, and the reason Perforce is still in business after all these years, is that workspaces are a fantastic way to pare down multi-million file projects for developers while still making it easy for build and release to pull all the source together from one authoritative source. Workspaces are one of the key reasons Perforce can scale as well as it does.

我认为来自 Git 的人很容易觉得整个工作区概念比它的价值要麻烦得多。与克隆一些 Git 存储库相比，这无疑是正确的。工作空间大放异彩的地方，以及 Perforce 在这么多年后仍在营业的原因是，工作空间是为开发人员削减数百万个文件项目的绝佳方式，同时仍然可以轻松构建和发布，将所有源代码汇集在一起一个权威来源。工作区是 Perforce 能够像它那样扩展的关键原因之一。

Workspaces are also nice in that the layout of files in the depot and the layout on the user's machine can vary if need be. Many companies organize their depot to reflect the organization of their company so that it is easy for people to find content by business unit or project. However their build system couldn't care less about this hierarchy; the workspace allows them to remap their depot hierarchy in whatever way makes sense to their tools. I have also seen this used by companies who are using extremely inflexible build systems that require code to be in very specific configurations that are utterly confusing to humans. Workspaces allow these companies to have a source hierarchy that is human navigable while their build tools get the structure they need.

工作区也很好，因为软件仓库中的文件布局和用户机器上的布局可以根据需要而变化。许多公司组织他们的仓库来反映他们公司的组织，以便人们可以轻松地按业务单位或项目查找内容。然而，他们的构建系统并不关心这个层次结构；工作区允许他们以对他们的工具有意义的任何方式重新映射他们的仓库层次结构。我还看到公司使用非常不灵活的构建系统，这些系统需要代码处于非常特定的配置中，这对人类来说是完全混乱的。工作区允许这些公司拥有一个可供人类导航的源层次结构，同时他们的构建工具获得所需的结构。

Workspaces in Perforce are not only used to map the set of files a user wants to work with, but they are also used by the server to track exactly which revisions of each file the user has synced. This allows the system to send the correct set of files to the user when syncing without having to scan the files to see which files need to be updated. With large amounts of data this can be a sizable performance win. This is also very popular in industries that have very strict auditing rules; Perforce admins can easily track and log which developers have synced which files.

Perforce 中的工作区不仅用于映射用户想要使用的文件集，而且服务器还使用它们来准确跟踪用户同步的每个文件的哪些修订版。这允许系统在同步时向用户发送正确的文件集，而无需扫描文件以查看哪些文件需要更新。对于大量数据，这可能会带来可观的性能优势。这在审计规则非常严格的行业中也很受欢迎；Perforce 管理员可以轻松跟踪和记录哪些开发人员同步了哪些文件。

For more information on the full power of Perforce workspaces read Configuring P4.

有关 Perforce 工作区全部功能的更多信息，请阅读配置 P4。

Explicit Checkout vs. Implicit Checkout

显式结账与隐式结账

One of the biggest challenges for users moving from Git to Perforce is the concept of explicit checkout. If you are accustomed to the Git/SVN/CVS workflow of changing files and then telling the version control system to look for what you've done, it can be an extremely painful transition.

从 Git 迁移到 Perforce 的用户面临的最大挑战之一是显式结账的概念。如果您习惯了 Git/SVN/CVS 更改文件然后告诉版本控制系统查找您所做的工作的工作流程，这可能是一个非常痛苦的过渡。

The good news is that if you so choose you can work with a Git style workflow in Perforce. In Perforce you can set "allwrite" option on your workspace. This will tell Perforce that all files should be written to disk with the writable bit set. You may then change any file you wish without explicitly telling Perforce. To have Perforce reconcile those changes you made you can run "p4 status". It will open files for add, edit, and delete as appropriate. When working this way you will want to use "p4 update" instead of "p4 sync" to get new revisions from the server; "p4 update" checks for changes before syncing so will not clobber your local changes if you haven't run "p4 status" yet.

好消息是，如果您愿意，您可以在 Perforce 中使用 Git 风格的工作流程。在 Perforce 中，您可以在工作区中设置“allwrite”选项。这将告诉 Perforce 所有文件都应该写入磁盘并设置可写位。然后您可以更改任何您想要的文件，而无需明确告诉 Perforce。要让 Perforce 协调您所做的更改，您可以运行“p4 status”。它将根据需要打开文件以进行添加、编辑和删除。以这种方式工作时，您将需要使用“p4 update”而不是“p4 sync”从服务器获取新修订；“p4 update”在同步之前检查更改，因此如果您还没有运行“p4 status”，则不会破坏您的本地更改。

Why Explicit Checkout?

为什么要显式结帐？

A question I frequently receive is "why would you ever want to use explicit checkout?" It can at first blush seem to be a crazy design decision, but explicit checkout does have some powerful benefits.

我经常收到的一个问题是“你为什么要使用显式结账？” 乍一看，这似乎是一个疯狂的设计决定，但显式结账确实有一些强大的好处。

One reason for using explicit checkout is it removes the need to scan files for content changes. While with smaller projects calculating hashes for each file to find differences is fairly cheap, many of our users have millions of files in a workspace and/or have files that are 100's of megabytes in size, if not larger. Calculating all the hashes in those cases is extremely time consuming. Explicit checkout lets Perforce know exactly which files it needs to work with. This behavior is one of the reasons Perforce is so popular in large file industries like the game, movie, and hardware industries.

使用显式结帐的原因之一是它不需要扫描文件以进行内容更改。虽然对于较小的项目，计算每个文件的散列以找到差异相当便宜，但我们的许多用户在工作区中有数百万个文件和/或文件大小为 100 兆字节，如果不是更大的话。在这些情况下计算所有散列非常耗时。显式检出让 Perforce 确切知道它需要处理哪些文件。这种行为是 Perforce 在大型文件行业（如游戏、电影和硬件行业）中如此受欢迎的原因之一。

Another benefit is explicit checkout provides a form of asynchronous communication that lets developers know generally what their peers are working on, or at least where. It can let you know that you may want to avoid working in a certain area so as to avoid a needless conflict, or it can alert you to the fact that a new developer on the team has wandered into code that perhaps they don't need to be editing. My personal experience is that I tend to work either in Git or using Perforce with allwrite on projects where I'm either the only contributor or an infrequent contributor, and explicit checkout when I'm working tightly with a team. Thankfully the choice is yours.

另一个好处是显式结账提供了一种异步通信形式，让开发人员大致了解他们的同行正在做什么，或者至少在哪里。它可以让您知道您可能希望避免在某个领域工作以避免不必要的冲突，或者它可以提醒您团队中的新开发人员已经徘徊在他们可能不需要的代码中正在编辑。我的个人经验是，在我是唯一贡献者或不频繁贡献者的项目中，我倾向于使用 Git 或使用 Perforce 和 allwrite 工作，并在我与团队紧密合作时进行显式结帐。谢天谢地，选择权在你。

Explicit checkout also plays nicely with the Perforce concept of pending changelists. Pending changelists are buckets that you can put your open files into to organize your work. In Git you would potentially use different branches as buckets for organizing work. Branches are great, but sometimes it is nice to be able to organize your work into multiple named changes before actually submitting to the server. With the Perforce model of potentially mapping multiple branches or multiple projects into one workspace, pending changelists make it easy to keep separate changes organized.

显式结帐也与 Perforce 的待定更改列表概念很好地配合。待定更改列表是您可以将打开的文件放入其中以组织您的工作的存储桶。在 Git 中，您可能会使用不同的分支作为组织工作的存储桶。分支很棒，但有时在实际提交到服务器之前能够将您的工作组织成多个命名更改是很好的。由于 Perforce 模型可能将多个分支或多个项目映射到一个工作区，挂起的更改列表可以轻松地组织单独的更改。

If you use an IDE for development such as Visual Studio or Eclipse I highly recommend installing a Perforce plugin for your IDE. Most IDE plugins will automatically checkout files when you start editing them, freeing you from having to do the checkout yourself.

如果您使用 IDE 进行开发，例如 Visual Studio 或 Eclipse，我强烈建议为您的 IDE 安装 Perforce 插件。大多数 IDE 插件会在您开始编辑文件时自动检出文件，让您无需自己进行检出。

Perforce Replacements For Git Features

Git 功能的 Perforce 替换

• git stash==> p4 shelve
• git local branching ==> either Perforce shelves or task branches
• git blame==> p4 annotateor Perforce Timelapse Viewfrom the GUI

• git stash==> p4 shelve
• git 本地分支 ==> Perforce 货架或任务分支
• git blame==>p4 annotate或来自 GUI 的Perforce Timelapse View

Working Disconnected

工作断开

There are two options for working disconnected from the Perforce versioning service (that's our fancy term for the Perforce server).

有两种与 Perforce 版本控制服务断开连接的工作选项（这是我们对 Perforce 服务器的奇特术语）。

1) Use P4Sandbox to have full local versioning and local branching

1) 使用 P4Sandbox 拥有完整的本地版本和本地分支

2) Edit files as you please and use 'p4 status' to tell Perforce what you've done

2) 随意编辑文件并使用“p4 status”告诉 Perforce 你做了什么

With both the above options you can opt to use the "allwrite" setting in your workspace so that you do not have to unlock files. When working in this mode you will want to use the "p4 update" command to sync new files instead of "p4 sync". "p4 update" will check files for changes before syncing over them.

通过上述两个选项，您可以选择在工作区中使用“allwrite”设置，这样您就不必解锁文件。在此模式下工作时，您需要使用“p4 update”命令来同步新文件而不是“p4 sync”。“p4 update”将在同步文件之前检查文件的更改。

Perforce Quickstart

Perforce 快速入门

All the following examples will be via the command line.

以下所有示例都将通过命令行进行。

1) Configure your connection to Perforce

1) 配置与 Perforce 的连接

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

You can stick these settings in your shell config file, use p4 setto save them on Windows and OS X, or use a Perforce config file.

您可以将这些设置p4 set保留在您的 shell 配置文件中，用于将它们保存在 Windows 和 OS X 上，或者使用 Perforce 配置文件。

1) Create a workspace

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) Get the files from the server

2）从服务器获取文件

cd /Users/matt/work
p4 sync

3) Checkout the file you want to work on and modify it

3) 签出要处理的文件并进行修改

p4 edit main/foo; 
echo cake >> main/foo

4) Submit it to the server

4）提交给服务器

p4 submit -d "A trivial edit"

5) Run p4 help simpleto see the basic commands that you will need to work with Perforce.

5) 运行p4 help simple以查看使用 Perforce 所需的基本命令。

回答by damian

The biggest difference between git and p4, which none of the existing answers address, is that they use different units of abstraction.

git 和 p4 之间的最大区别（现有答案都没有解决）在于它们使用不同的抽象单元。

• In git, the abstraction is the patch(aka diff, aka changeset). A commit in git is essentially the output of running diffbetween the previous and current state of the files being committed.
• In perforce, the abstraction is the file. A commit in p4 is the full content of the files in the commit at that point in time. This is organised into a changelist, but the revisions themselves are stored on a per-file basis, and the changelist simply collects different revisions of the files together.

• 在 git 中，抽象是补丁（又名差异，又名变更集）。git 中的提交本质上是在提交diff的文件的先前状态和当前状态之间运行的输出。
• 在perforce中，抽象是文件。p4 中的提交是该时间点提交中文件的完整内容。这被组织成一个更改列表，但修订本身存储在每个文件的基础上，并且更改列表只是将文件的不同修订收集在一起。

Everything else flows from this difference. Branching and merging in git is painless because, from the perspective of git's abstraction, every file can be fully reconstructed by applying a set of patches in order, and therefore to merge two branches, you just need to apply all the patches on the source branch that aren't present in the target branch to the target branch in the correct order (assuming there are no patches on both branches that overlap).

其他一切都源于这种差异。在 git 中分支和合并是无痛的，因为从 git 抽象的角度来看，每个文件都可以通过依次应用一组补丁来完全重建，因此合并两个分支，您只需要在源分支上应用所有补丁不以正确顺序出现在目标分支中的目标分支（假设两个分支上没有重叠的补丁）。

Perforce branches are different. A branch operation in perforce will copy files from one subfolder to another, and then mark the linkage between the files with metadata on the server. To merge a file from one branch to another (integrationin perforce terms), perforce will look at the complete contentof the file at the 'head' of on the source branch and the complete contentof the file at the head of the target branch and if necessary merge using a common ancestor. It is unable to apply patches one by one like git can, which means manual merges happen more often (and tend to be more painful).

Perforce 分支是不同的。perforce 中的分支操作会将文件从一个子文件夹复制到另一个子文件夹，然后在服务器上用元数据标记文件之间的链接。从一个分支合并文件到另一个（integrationPerforce中的术语），Perforce公司将着眼于完整内容的文件在对源科的“头”和完整内容的文件，在目标分支的头如有必要，使用共同祖先进行合并。它无法像 git 那样一个一个地应用补丁，这意味着手动合并发生得更频繁（并且往往更痛苦）。

回答by jamesdlin

There's probably not a lot of such documentation because Perforce is a pretty traditional revision control system (closer to CVS, Subversion, etc.) and normally is considered to be less complicated than modern distributed revision control systems.

可能没有很多这样的文档，因为 Perforce 是一个非常传统的修订控制系统（更接近 CVS、Subversion 等）并且通常被认为没有现代分布式修订控制系统那么复杂。

Trying to map commands from one to the other is not the right approach; concepts from centralized vs. distributed revision control systems aren't the same. Instead, I'll describe a typical workflow in Perforce:

试图将命令从一个映射到另一个不是正确的方法；集中式和分布式修订控制系统的概念并不相同。相反，我将描述 Perforce 中的典型工作流程：

1. Run p4 editon each file you want to edit. You need to tell Perforce which files you're editing. If you're adding new files, use p4 add. If you're deleting files, use p4 delete.
2. Make your code changes.
3. Run p4 changeto create a changeset. Here you can create a description of your change and optionally add or remove files from your changeset too. You can run p4 change CHANGE_NUMBERto edit the description later if necessary.
4. You can make additional code changes if you need to. If you need to add/edit/delete other files, you can use p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Run p4 syncto pull in the latest changes from the server.
6. Run p4 resolveto resolve any conflicts from syncing.
7. When you're ready to submit your change, run p4 submit -c CHANGE_NUMBER.

1. p4 edit在您要编辑的每个文件上运行。您需要告诉 Perforce 您正在编辑哪些文件。如果要添加新文件，请使用p4 add. 如果要删除文件，请使用p4 delete.
2. 更改您的代码。
3. 运行p4 change以创建变更集。您可以在此处创建更改的描述，也可以选择从变更集中添加或删除文件。p4 change CHANGE_NUMBER如有必要，您可以稍后运行以编辑描述。
4. 如果需要，您可以进行其他代码更改。如果您需要添加/编辑/删除其他文件，您可以使用p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. 运行p4 sync以从服务器获取最新更改。
6. 运行p4 resolve以解决同步中的任何冲突。
7. 当您准备好提交更改时，运行p4 submit -c CHANGE_NUMBER.

You can use p4 revertto revert your changes to files.

您可以使用p4 revert来恢复对文件的更改。

Note that you can be working on multiple changesets simultaneously as long as none of their files overlap. (A file in your Perforce client can be open in only one changeset at a time.) This sometimes can be convenient if you have small, independent changes.

请注意，只要它们的文件没有重叠，您就可以同时处理多个变更集。（您的 Perforce 客户端中的文件一次只能在一个变更集中打开。）如果您有小的、独立的变更，这有时会很方便。

If you find yourself needing to edit files that you already have open in another changeset, you can either create a separate Perforce client or you can stash your existing changeset for later via p4 shelve. (Unlike git stash, shelving does not revert the files in your local tree, so you must revert them separately.)

如果您发现自己需要编辑已经在另一个变更集中打开的文件，您可以创建一个单独的 Perforce 客户端，或者您可以通过p4 shelve. （与 不同git stash，搁置不会还原本地树中的文件，因此您必须单独还原它们。）