那么哪个更好，使用 git-p4 或只是将 .git 目录滑入工作目录并让 perforce 忽略它？答案

【问题标题】：So which is better, using git-p4 or just sliding a .git directory into the working directory and having perforce ignore it?那么哪个更好，使用 git-p4 或只是将 .git 目录滑入工作目录并让 perforce 忽略它？
【发布时间】：2010-01-21 16:27:54
【问题描述】：

我知道之前有come up，但在我看到的帖子中几乎没有日常个人经历。只有几个回应。我很想听听使用 git-p4 的人的意见，或者在 Perforce 存储库中“在幕后”使用过 git，或者最好两者兼而有之。
对于那些只在另一个版本控制下使用 git 的人，我很想听听您如何处理通知主要版本控制的更改。具体来说，使用 git/perforce，当您完成并准备将更改提交到 perforce 服务器时，您如何处理告诉 perforce 发生了哪些更改？
我已经使用 git 研究了提交后挂钩，但我很想听听任何其他想法。

【问题讨论】：

您是在本地使用 git，还是打算与他人共享存储库？

标签： git version-control perforce

【解决方案1】：

我在工作中使用了 git-p4。这是一个双向桥梁，所以如果你想使用 git，然后将本地提交提交回 p4，这是一个不错的方法。然而，我们的办公室政策有一种文化，即少量大量提交而不是大量小提交，因此我必须将所有更改重新设置为一个补丁，然后再提交回 p4。我本来希望保留细粒度的本地历史，但一次又一次提交，但永远无法管理。

适当的更改通知。 git-p4 为自上次签入后的每个签入创建补丁，并将它们作为单独的变更集提交。这种镜像反映了您在 git 存储库中正在处理的主分支的历史。

【讨论】：

+1。一个专门用于细粒度本地历史（您工作的地方）的 repo R1 怎么样，推送到您由 P4（RP4）管理的 repo，以及您可以在哪里执行 rebase -i there （保留小提交）？当使用来自 Perforce 的新数据更新 RP4 时，R1 可以从 RP4 获取，并将远程/分支重新定位在其自己的详细分支之上。只是在我的头上。可能会引发太多的冲突而不实用。
这听起来可行但相当复杂。你确定你想要 git that bad？
仅当您想保留两组相同的历史记录时，因为使用 Git 克隆 repo 非常容易。但这可能是矫枉过正，只是作为一种快速的心理锻炼;）

【解决方案2】：

我将 git 与 TFS 一起使用，并选择使用选项 2：将 .git 目录滑入并让 TFS 忽略它。我这样做的原因与@Noufal 所做的相同，我们这里的文化是“一次大提交”与我在 Git 中所做的数十个微小提交。由于我每天只提交一到两次 TFS，因此我不值得在提交后挂钩或变基或其他任何东西上乱七八糟。

【讨论】：

【解决方案3】：

我想这真的取决于你的 perforce 存储库的布局 - 如果你正在处理它的一个相对较小的部分，那么我可能会直接删除 .git 目录。这是最少的路径到目前为止，我已经成功地在较小的项目中使用了它。

也就是说，我在较大的存储库上一直在努力使用这种方法，这可能与我工作的工作流程以及这一切的管理开销一样大。我还没有看 git-p4，但我有兴趣进一步研究它。

【讨论】：

【解决方案4】：

我这样做的方式是在 git 中拥有一个 master 分支和 feature 分支，然后在一个 feature 分支上使用 git diff --name-only master 来找出我为特定功能更改了哪些文件。然后我将这些文件签出到 Perforce 更改列表中并提交。

...嗯，或多或少... :) 在实践中，我们使用 Code Collaborator 进行代码审查，所以我在开始研究该功能和提交文件进行代码审查之间的某个时间检查文件（它不会什么时候真的不重要）。然后我在代码审查之前检查我是否已经使用上面的 git 命令获得了我应该拥有的所有文件。（实际上，因为我很偏执，我现在在我的源目录中执行git clean -xdf 并执行 Perforce“协调离线工作”以仔细检查我将要提交的内容。然后我对整个文件进行完全重建项目。毕竟，破坏构建是令人尴尬的。）完成所有审查后，我只需照常提交变更列表。

这确实有点小题大做，但现在我已经习惯了它并没有那么糟糕——而且它比仅仅使用 Perforce 进行大量提交要好得多，并且在没有任何版本控制的情况下有效地工作几天一次:)

【讨论】：