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