我工作的地方使用Perforce环境，但在我们的功能完成并准备好进行测试之前，我们不允许办理登机手续。我需要能够进行本地提交，因为有时我已经检查了超过50个文件一周而没有对我的更改进行任何版本控制。
Git符合我的目的，但我不确定如何将其设置为与我的其他环境最佳集成。
我的目标是：
似乎在我本地工作区的根目录下创建一个git存储库会起作用，但我有一些问题...
有谁可以给我一些关于此的提示？我一直在看git中的子模块作为一种可能减少git repo大小的方法，因为perforce repo中有很多部分我不需要进行版本控制。
答案 0 :(得分：1)
答案 1 :(得分：1)
我目前正在使用这个工作流程，而且非常棒
出于公司原因，我无法使用git-p4命令，但我的客户端工作区目录中有一个git repo。我们的设置只有配置代码签入源代码控制，其余的开发设置存储在ZIP中。因此，我无论如何都不会在工作区根目录上调和，这有额外的好处，不需要明确忽略.git。
解决你的观点：
初始提交可能是......好吧，而不是最快的。它没有克隆现有的回购，它从头开始构建一个回收。
偶尔我会保存+提交我正在处理的内容，
git checkout master && p4 sync && git add --all . && git commit -mupdate && git checkout feature-branch
然后继续破解。合并在Git中比在Perforce中更容易更多更顺畅，所以通常你不会因为冲突而打破焦点。 @p4mataway告诉我他们正在努力合并更好，所以这样做会很好看。
我开启了＃allwrite＆＃39;工作区选项（不要将未经编辑的文件保持为只读），当我准备好检查某些内容时，我会将该分支合并到master，然后在P4V中进行协调。我也是从命令行那样做的，但又是公司的原因。长话故事。
Git在处理涉及对同一文件进行多项更改的功能时非常有用，因为长期未决的更改往往会发生这种情况 - 通常是需要重置应用程序数据库的数据库架构更改我们现在不想在测试服务器上执行此操作，因为QA处于场景中间。更改列表保留的时间越长，某些不相关的工作就越有可能触摸其中一个相同的文件，并且能够在本地进行分支，从而使更改不会卡在一起。仅此功能就足以使整个设置完全有价值。
免责声明 - 我不打算永远保留这个Git回购。一旦通过即将进行的服务器升级解决了一些公司原因，我将能够使用我们当前环境不支持的一些非常闪亮的Perforce功能。
答案 2 :(得分：0)
我在使用StarTeam和git时做同样的事情。我不熟悉perforce语法，但概念应该匹配。
首先，初始git提交总是很慢。之后，扫描已更改的文件可能需要5-10秒才能进行暂存，但提交应该在大多数时间几乎立即发生。对于上下文，我们的代码库有大约50,000个版本化文件。
我让master与StarTeam保持同步，但不直接在其中进行任何开发工作。我做了git checkout master，然后进行StarTeam更新，然后进行git add and commit。
然后，对于我的工作，我创建一个新分支，在那里完成所有工作，在master中执行另一个StarTeam更新，并在提交到StarTeam之前将我的功能分支合并回master。因此，StarTeam检查输入和输出都在master完成，并且开发总是在其他分支中完成，这使得StarTeam更新保持清洁。
这种混合方法还有一些其他好处，例如能够将部分工作搁置一段时间用于代码审查，字段问题或其他任何方面。我目前在各种使用状态下有5个git分支。放入临时调试代码也很不错。
答案 3 :(得分：0)
这是一个粗略的解决方案。从p4同步后，在该目录中执行git init，添加所有文件并提交它们。你的工作完全忽略了git，然后添加并提交回p4。
在this question中讨论了这个和一些相关的事情。
答案 4 :(得分：0)
无论如何，当你使用P4V时，我建议你至少尝试相对较新的offline support选项。它允许你获得你要求的大部分内容（除了使用Git）。