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

我知道这以前有过，但在我看到的帖子中，几乎没有日常的个人经历。只有几个回答。 我希望听到使用git-p4的人，或者在Performe回购中“秘密”使用git的人，或者最好两者都使用。
对于那些只在另一个版本控制下使用git的人，我很想听听您如何处理通知主版本控制更改的问题。具体来说，使用git/perforce，当您完成并准备将更改提交到perforce服务器时，您如何处理告诉perforce发生了哪些更改的问题？

---

我已经研究过git的提交后钩子，但是我很想听听其他的想法。

我在工作中使用了git-p4。这是一个双向网桥，所以如果您想使用git，然后将本地提交提交回p4，这是一个很好的方法。然而，我们的office策略有一种文化，即少量的大规模提交，而不是许多小的提交，因此我必须在提交回p4之前将所有更改重新设置为一个补丁。我本想维护细粒度的本地历史，但一次就提交回来，但永远无法管理

---

---

适当的变更通知

git-p4

为自上次签入以来的每次签入创建修补程序，并将其作为单独的变更集提交。这类镜像了您正在git存储库中处理的主要分支的历史记录。

我将git与TFS一起使用，并选择了选项2：将.git目录滑入并让TFS忽略它。我这样做的原因与@Noufal的原因相同，我们这里的文化是“一次大提交”而不是我在Git中做的几十次小提交。由于我每天只向TFS提交一到两次，所以我不值得在提交后胡乱使用挂钩、回扣或其他任何东西。

我想这真的取决于您的Performce存储库的布局-如果您处理的是相对较小的部分，那么我可能会直接删除.git目录。这是迄今为止阻力最小的途径，我已经成功地将其应用于较小的项目中

---

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

我这样做的方式是在git中有一个主分支和功能分支，然后在功能分支上使用

git diff--name only master

，找出我为特定功能更改了哪些文件。然后我将这些文件签出到performe变更列表中并提交

……嗯，或多或少……：）实际上，我们使用CodeCollaborator进行代码审查，所以我会在开始使用该特性和提交文件进行代码审查之间的某个时间检查文件（何时提交其实并不重要）。然后，在代码检查之前，我检查是否已经使用上面的git命令获得了应该拥有的所有文件。（事实上，因为我有妄想症，我现在在我的源代码目录中做了一个

git clean-xdf

，并做了一个Perforce“协调脱机工作”来再次检查我将要提交的内容。然后我对整个项目进行全面重建。毕竟，破坏构建是令人尴尬的。）一旦所有的审查完成，我就正常提交变更列表

---

这是一个有点虚假的东西，真的，但现在我已经习惯了，它还不是那么糟糕——而且它比只使用Perforce进行大规模提交要好得多，并且一次有效地工作几天而不使用任何版本控制：）

+1。一个专门用于细粒度本地历史（您工作的地方）的repo R1，推送到由P4（RP4）管理的repo，在那里您可以执行rebase-i（保留小提交），怎么样？。当使用Perforce的新数据更新RP4时，R1可以从RP4获取数据，并在其自己的详细分支上重新设置远程/分支的基础。只是在我头上想了想。这可能会引发太多的冲突，不太现实。这听起来可行，但相当复杂。你真的那么想要git吗？除非你想保留两组相同的历史记录，因为用git克隆repo非常容易。但这可能是矫枉过正，只是想作为一种快速的心理锻炼；）您是将git用于您自己的本地使用，还是计划与其他人共享存储库？