如何设置 Git 进行本地提交，同时使用 P4 进行远程提交？
我工作的地方使用 Perforce 环境，但在我们的功能完成并准备好进行测试之前，我们不允许签入。我需要能够进行本地提交，因为有时一周内我会签出 50 个以上的文件，而我的更改却没有任何版本控制。
Git 符合我的目的，但我不确定如何设置它以最好地与我的环境的其他部分集成。
我的目标是：
- 在开发某个功能时，我会 喜欢能够完全忽略 尽可能多地执行、编辑和提交 如我所愿（在 Git 中）。
- 在提交功能之前，我需要 能够进入 P4V 或 P4Win 比较文件并确保 一切都是最新的，之后 测试我想要我所有的改变 在一次提交中。
似乎在我的本地工作空间的根目录中创建一个 git 存储库是可行的，但我有一些问题......
- 这个存储库中有大量文件，并且至少在初始提交时 git 正在爬行。
- 当我从 Perforce“获取最新版本”时，我需要能够轻松更新 git 存储库
- 我不想在编辑之前检查 Perforce 中的每个文件，也不想执行强制操作在 Perforce 中同步，因为它们是未签出的可写文件。
有人可以给我一些关于这个的提示吗？我一直在研究 git 中的子模块，作为一种潜在地减少 git 存储库大小的方法，因为 perforce 存储库的很多部分我不需要版本控制。
Where I work uses a Perforce environment but we are not allowed to check in until our features are completed and ready to be tested. I need to be able to do local commits because at times I have had upwards of 50 files checked out for a week without any versioning on my changes.
Git fits my purpose, but I am not sure how to set it up to best integrate with the rest of my environment.
My goals are:
- When working on a feature I would
like to be able to completely ignore
Perforce and edit and commit as much
as i please (in Git). - Before submitting a feature, I need
to be able to go into P4V or P4Win to
diff the files and make sure
everything is up to date, and after
testing I would like all my changes
to be in a single commit.
It seems like creating a git repository at the root directory of my local workspace would work, but I have some issues...
- There are a massive amount of files in this repository and at least with the initial commit git is crawling.
- I need to be able to easily update the git repository when I "get latest" from Perforce
- I don't want to have to deal with checking out every file in Perforce before I edit it, nor do I want to have to do a Force Sync in Perforce because their are writable files that aren't checked out.
Can anyone give me some tips about this? I've been looking at submodules in git as a way to potentially reduce the size of the git repo as there are a lot of portions of the perforce repo that I don't need versioning on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你应该使用 git-p4。这答案也可能有帮助。
You should go with git-p4. This answer might be helpful as well.
我目前正在使用这个工作流程，它非常棒。
出于公司原因，我无法使用 git-p4 命令，但我的客户端工作空间目录中有一个 git 存储库。我们的设置仅将配置代码签入源代码管理，其余的开发设置存储在 ZIP 中。因此，无论如何我都不会在工作区根目录上进行协调，这还有一个额外的好处，那就是不需要显式忽略
.git。解决你的观点：
初始提交预计会......嗯，不是最快的。它不是克隆现有的存储库，而是从头开始构建一个存储库。
偶尔我会保存+提交我正在做的事情，
然后继续破解。 Git 中的合并往往比 Perforce 中的合并更加顺利，因此通常您不必因为冲突而失去焦点。 @p4mataway 告诉我，他们正在努力更好地合并，所以看起来会很漂亮。< /p>
我打开了“allwrite”工作区选项（不要将未编辑的文件保持为只读），当我准备好签入某些内容时，我会将该分支合并到
master然后在 P4V 中进行协调。我也会从命令行执行此操作，但又是出于公司原因。长话短说。在处理涉及对同一文件进行多次更改的功能时，Git 对我非常有用，因为长期未决的更改往往会发生这种情况 - 通常是数据库架构更改，需要重置我们的应用程序的数据库，而我们不想这样做现在在测试服务器上，因为 QA 处于场景中间。更改列表保留的时间越长，一些不相关的工作就越有可能触及相同的文件之一，并且能够在本地进行分支可以防止更改粘在一起。仅此功能就足以使整个设置完全值得。
免责声明 - 我不打算永远保留这个 Git 存储库。一旦通过即将到来的服务器升级解决了一些公司原因，我将能够使用我们当前环境不支持的一些非常闪亮的 Perforce 功能。
I am currently using exactly this workflow and it's pretty great
For corporate reasons I can't use the git-p4 commands, but I've got a git repo living inside my client workspace directory. Our setup has configuration-code-only checked in to source control, with the rest of the dev setup stored in a ZIP. Thus I never reconcile on the workspace root anyway, which has the added bonus of not needing to explicitly ignore
.git.Addressing your points:
The initial commit can be expected to be...well, not the speediest. It's not cloning an existing repo, it's building one up from scratch.
Occasionally I'll save+commit what I'm working on,
and then continue to hack. Merges tend to be much smoother in Git than in Perforce so usually you won't have to break focus because of conflicts. @p4mataway told me that they're working on merging better, though, so that'll be neat to see.
I turned on the 'allwrite' workspace option (don't keep unedited files read-only) and when I'm ready to check something in, I'll merge that branch down to
masterand then Reconcile in P4V. I'd do that from the command-line too but, corporate reasons again. Long story.Git has been tremendously useful to me when dealing with features that involve multiple changes to the same file, as tends to happen with long-pending changes - typically database schema changes that require our application's database to be reset and we don't want to do that on the test servers right now because QA are in the middle of scenarios. The longer a changelist stays around, the more likely some unrelated work is to touch one of the same files, and being able to branch locally keeps the changes from getting stuck together. That feature alone is enough to make this whole setup entirely worthwhile.
Disclaimer - I don't intend to keep this Git repo around forever. Once some of the Corporate Reasons are resolved with an upcoming server upgrade I'll be able to use some very shiny Perforce features that our current environment doesn't support.
我在使用 StarTeam 和 git 时也做同样的事情。我不熟悉 perforce 语法，但概念应该匹配。
首先，最初的 git 提交总是很慢。此后，可能需要 5-10 秒来扫描更改的文件以进行暂存，但大多数情况下提交应该几乎立即发生。对于上下文，我们的代码库大约有 50,000 个版本化文件。
我使
master与 StarTeam 保持同步，但不直接在其中进行任何开发工作。我执行git checkout master，然后执行 StarTeam 更新，然后执行 git add 和提交。然后，对于我的工作，我创建一个新分支，在其中完成所有工作，在
master中进行另一个 StarTeam 更新，并将我的功能分支合并回master，然后再提交明星队。因此，StarTeam 的签入和签出均在master中完成，并且开发始终在其他分支中完成，这使 StarTeam 更新保持干净。这种混合方法还有其他一些好处，例如能够将部分工作暂时搁置以进行代码审查、现场问题或其他任何事情。我目前有 5 个处于不同使用状态的 git 分支。放入临时调试代码也非常好。
I do the same thing at work with StarTeam and git. I'm not familiar with perforce syntax, but the concepts should match.
First of all, the initial git commit is always slow. After that, it might take 5-10 seconds to scan changed files for staging, but the commit should happen nearly instantaneously most of the time. For context, our code base has approximately 50,000 versioned files.
I keep
mastersynced up with StarTeam, but don't do any development work directly in it. I do agit checkout master, then do a StarTeam update, then a git add and commit.Then for my work, I make a new branch, do all my work in there, do another StarTeam update in
master, and merge my feature branch back intomasterbefore committing to StarTeam. Thus, StarTeam check ins and outs are all done inmaster, and development is always done in other branches, which keeps the StarTeam updates clean.This mixed approach has some other nice benefits, like being able to put partial work on hold for a while for code reviews, field issues, or whatever. I currently have 5 git branches in various states of use. It's also real nice for putting in temporary debugging code.
这是一个粗略的解决方案。从
p4同步后，在该目录中执行git init，添加所有文件并提交它们。完全忽略 git 来完成您的工作，然后将它们添加并提交回p4中。这和一些相关的事情在 这个问题。
Here's a crude solution. After you sync from
p4, Do agit initin that directory, add all the files and commit them. Do your work completely ignoring git and then add and commit them back intop4.This and some related things were discussion in this question.
无论如何，由于您正在使用 P4V，我建议您至少尝试一下相对较新的 离线支持选项。它可以满足您所要求的大部分内容（除了使用 Git）。
As you are using P4V anyway, I would recommend you to at least try the relatively new offline support option. It allows you to most of what you're asking for (except for using Git).