GIT 与 Perforce - 两个 VCS 将进入...一个将离开
所以我正在工作中推销 GIT。 我需要做的第一件事是让每个人相信 GIT 更擅长他们已经习惯做的事情。 我们目前使用 Perforce。 还有其他人经历过类似的销售吗？ 有什么好的链接/建议吗？
最大的胜利之一是我们可以在与网络断开的情况下使用它。 IMO 的另一个胜利是添加/结账的处理方式。 欢迎更多积分！ 我们总共有大约 10-20 名开发人员。
So I'm in the process of getting GIT sold at work. First thing I need is to convince everyone that GIT is better at what they're already used to doing. We currently use Perforce. Anybody else go through a similar sale? Any good links/advice?
One of the big wins is that we can work with it disconnected from the network. Another win IMO is the way adds/checkouts are handled. More points are welcome! Also we have about 10-20 devs total.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
我们已经使用 Git 一段时间了，最近我们的 Git 服务器的硬盘崩溃了，我们无法恢复到最新状态。 我们设法回到几天前的状态。 当服务器恢复时。 团队中的每个人都拉/推了他们的更改，瞧，服务器回到了当前状态。
We have been using Git for sometime, recently our Git server's harddrive crashed and we could not revert back to the latest state. We managed to get back to few days old state. When the server was back up. Everyone in the team pulled/pushed their changes and voila, the server is back to current state.
Perforce 和 git（也是最常提到的一个）之间的一个重要区别是它们各自对巨大二进制文件的处理。
例如，在视频游戏开发公司的一名员工的博客中： http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
然而，重要的是，之间的速度差异git 和 perforce，当你有一个巨大的 6GB 存储库，包含从文档到曾经构建的每个二进制文件的所有内容（最后，哦，是的！实际的源代码历史记录）时，通常来自这样一个事实：大公司倾向于运行 Perforce，所以他们将其设置为将所有重要操作卸载到地下室的巨大服务器库中。
Perforce 的这一重要优势仅来自与 Perforce 无关的一个因素，即运行 Perforce 的公司能够负担得起上述服务器库。
而且，无论如何，最终 Perforce 和 git 是不同的产品。 Git 被设计为纯粹的 VCS，它在这方面比 Perforce 做得更好（因为它具有更多功能，通常更易于使用，特别是，用另一个人的话说，Perforce 中的分支就像执行开放式心手术，只能由专家完成:P) ( http://stevehanov.ca/ blog/index.php?id=50 ）
使用 Perforce 的公司获得的任何其他好处仅仅是因为 Perforce 不仅仅是一个 VCS，它还是一个文件服务器，并且具有许多其他用于测试的功能 。
最后：Git 是开源的，并且启动起来更加灵活，因此修补 git 以将重要操作卸载到运行大量昂贵硬件的中央服务器上并不是那么困难
The one important difference between Perforce and git (and the one most commonly mentioned) is their respective handling of huge binary files.
Like, for example, in this blog of an employee at a video game development company: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
However, the important thing is that, the speed difference between git and perforce, when you have a huge 6gb repository, containing everything from documentation to every binary ever built (and finally, oh yes! the actual source history), usually comes from the fact that huge companies tend to run Perforce, and so they set it up to offload all significant operations to the huge server bank in the basement.
This important advantage on Perforce's part comes only from a factor that has nothing whatsoever to do with Perforce, the fact that the company running it can afford said server bank.
And, anyway, in the end, Perforce and git are different products. Git was designed to be solely a VCS, and it does this far better than Perforce (in that it has more features, which are generally easier to use, in particular, in the words of another, branching in Perforce is like performing open-heart surgery, it should only be done by experts :P ) ( http://stevehanov.ca/blog/index.php?id=50 )
Any other benefits which companies that use Perforce gain have come merely because Perforce is not solely a VCS, it's also a fileserver, as well as having a host of other features for testing the performance of builds, etc.
Finally: Git being open-source and far more flexible to boot, it would not be so hard to patch git to offload important operations to a central server, running mounds of expensive hardware.
我认为我知道 GIT 获胜的一件事是它能够在所有文件上“保留行结尾”，而 perforce 似乎坚持将它们翻译成 Unix、Dos/Windows 或 MacOS9 格式（“\n”、“\ r\n" 或 "\r)。
如果您在 Windows 环境或混合操作系统环境中编写 Unix 脚本，这确实很痛苦，甚至不可能在每个文件扩展名的基础上设置规则。例如，它会将 .sh、.bash、.unix 文件转换为 Unix 格式，并将 .ccp、.bat 或 .com 文件转换为
GIT 中的 Dos/Windows 格式（我不确定这是否是默认的，一个选项） 。或者唯一的选项）你可以将其设置为“保留行结尾” 这意味着，你可以手动更改文件的行结尾，然后 GIT 会保留该格式，这在我看来是理想的。做事的方法，我不明白为什么这不是 Perforce 的一个选项，
实现这种行为的唯一方法就是将文件标记为二进制，这将是一个令人讨厌的黑客行为。解决缺少的功能。 除了必须对所有脚本等进行繁琐的操作之外，它还可能会破坏大多数差异等。
我们目前解决的“解决方案”是运行 sed 命令来删除所有回车符每次将脚本部署到 Unix 环境时。 这也不理想，特别是因为其中一些部署在 WAR 文件内，并且在解压它们时必须再次运行 sed 行。
我认为这只是给 GIT 带来很大优势的一点，我认为上面没有提到这一点。
编辑：在使用 Perforce 一段时间后，我想添加另外几条评论：
A）我真正怀念 Perforce 的是清晰的实例差异，包括更改、删除和添加的文件。 这可以在 GIT 中使用 git diff 命令实现，但在 Perforce 中，必须在记录更改之前检出文件，并且虽然您可能将主编辑器（如 Eclipse）设置为自动编辑文件时将其签出，有时您可能会以其他方式（记事本、unix 命令等）编辑文件。 而且新文件似乎根本不会自动添加，即使使用 Eclipse 和 p4eclipse 也是如此，这可能相当烦人。 因此，要找到所有更改，您必须在整个工作区上运行“Diff against...”，这首先需要一段时间才能运行，其次包括各种不相关的内容，除非您设置非常复杂的排除列表，这引出了我的下一点。
B) 在 GIT 中，我发现 .gitignore 非常简单且易于管理、阅读和理解。 然而，在 Perforce 中可配置的工作区忽略/排除列表似乎很笨重并且不必要地复杂。 我无法使用通配符进行任何排除。 我想做一些类似的事情
，排除服务器/主线内所有项目中的所有目标文件夹。 然而，这似乎并不像我预期的那样工作，我最终为每个项目添加了一行，例如：
以及 bin 文件夹、.classpath 和 .projet 文件等的类似行。
C) Perforce 有相当有用的变更列表。 但是，假设我进行了一组更改，检查所有更改并将它们放入更改列表中，然后在提交该更改列表之前处理其他事情。 如果我稍后对第一个更改列表中包含的其中一个文件进行更改，则该文件仍将位于该更改列表中，并且我不能稍后提交更改列表，假设它只包含我最初添加的更改（尽管它将是相同的文件）。 在 GIT 中，如果您添加一个文件并对其进行进一步更改，这些更改将不会被添加（并且仍会显示在 git diff 中，并且您将无法提交该文件当然，这并不像更改列表那样有用，因为您只有一组添加的文件，但在 GIT 中您可以只提交更改，因为这不会。实际上，您可以在推送它们之前处理其他更改，但是如果不推送之前的更改，您将无法推送稍后添加的任何其他内容。
I think the one thing that I know GIT wins on is it's ability to "preserve line endings" on all files, whereas perforce seems to insist on translating them into either Unix, Dos/Windows or MacOS9 format ("\n", "\r\n" or "\r).
This is a real pain if you're writing Unix scripts in a Windows environment, or a mixed OS environment. It's not even possible to set the rule on a per-file-extension basis. For instance, it would convert .sh, .bash, .unix files to Unix format, and convert .ccp, .bat or .com files to Dos/Windows format.
In GIT (I'm not sure if that's default, an option or the only option) you can set it up to "preserve line endings". That means, you can manually change the line endings of a file, and then GIT will leave that format the way it is. This seems to me like the ideal way to do things, and I don't understand why this isn't an option with Perforce.
The only way you can achieve this behavior, is to mark the files as binary. As I see that, that would be a nasty hack to workaround a missing feature. Apart from being tedious to have to do on all scripts, etc, it would also probably break most diffs, etc.
The "solution" that we've settled for at the moment, is to run a sed command to remove all carriage returns from the scripts every time they're deployed to their Unix environment. This isn't ideal either, especially since some of them are deployed inside WAR files, and the sed line has to be run again when they're unpacked.
This is just something I think gives GIT a great advantage, and which I don't think has been mentioned above.
EDIT: After having been using Perforce for a bit longer, I'd like to add another couple of comments:
A) Something I really miss in Perforce is a clear and instance diff, including changed, removed and added files. This is available in GIT with the
git diffcommand, but in Perforce, files have to be checked out before their changes are recorded, and while you might have your main editors (like Eclipse) set up to automatically check files out when you edit them, you might sometimes edit files in other ways (notepad, unix commands, etc). And new files don't seem to be added automatically at all, even using Eclipse and p4eclipse, which can be rather annoying. So to find all changes, you have to run a "Diff against..." on the entire workspace, which first of all takes a while to run, and secondly includes all kind of irrelevant things unless you set up very complicated exclusion lists, which leads me to the next point.B) In GIT I find the .gitignore very simple and easy to manage, read and understand. However, the workspace ignore/exclude lists configurable in Perforce seem unwieldy and unnecessarily complex. I haven't been able to get any exclusions with wildcards working. I would like to do something like
To exclude all target folders within all projects inside Server/mainline. However, this doesn't seem to work like I would have expected, and I've ended up adding a line for every project like:
And similar lines for bin folders, .classpath and .projet files and more.
C) In Perforce there are the rather useful changelists. However, assume I make a group of changes, check them all and put them in a changelist, to then work on something else before submitting that changelist. If I later make a change to one of the files included in the first changelist, that file will still be in that changelist, and I can't just later submit the changelist assuming that it only contains the changes that I originally added (though it will be the same files). In GIT, if you add a file and them make further changes to it, those changes will not have been added (and would still show in a
git diffand you wouldn't be able to commit the file without first adding the new changes as well. Of course, this isn't usefull in the same way the changelist can be as you only have one set of added files, but in GIT you can just commit the changes, as that doesn't actually push them. You could them work on other changes before pushing them, but you wouldn't be able to push anything else that you add later, without pushing the former changes as well.我没有使用 Git 的经验，但我有使用 Mercurial 的经验，它也是一个分布式 VCS。 这实际上取决于项目，但在我们的例子中，分布式 VCS 适合该项目，因为它基本上消除了频繁的损坏构建。
我认为这实际上取决于项目，因为有些更适合客户端-服务器 VCS，而另一些更适合分布式 VCS。
I have no experience with Git, but I have with Mercurial which is also a distributed VCS. It depends on the project really, but in our case a distributed VCS suited the project as basically eliminated frequent broken builds.
I think it depends on the project really, as some are better suited towards a client-server VCS, and others towads a distributed one.
以下是我不喜欢 git 的地方：
首先，我认为分布式的想法与现实背道而驰。 每个真正使用 git 的人都以集中的方式进行操作，甚至 Linus Torvalds 也不例外。 如果内核以分布式方式管理，这意味着我实际上无法下载“官方”内核源代码 - 不会有 - 我必须决定是否想要 Linus 的版本，还是 Joe 的版本，或比尔的版本。 这显然是荒谬的，这就是为什么有一个由 Linus 使用集中式工作流程控制的官方定义。
如果您接受您想要对您的东西进行集中定义，那么很明显服务器和客户端角色完全不同，因此客户端和服务器软件应该相同的教条变得纯粹是限制性的。 客户端和服务器数据应该相同的教条显然变得荒谬，特别是在一个拥有十五年历史的代码库中，没有人关心，但每个人都必须克隆。
我们真正想要做的就是把所有这些旧东西塞进柜子里，然后忘记它在那里，就像任何普通的 VCS 所做的那样。 git 每天通过网络来回传输这些数据这一事实是非常危险的，因为它会催促你修剪它。 这种修剪涉及很多繁琐的决定，而且可能会出错。 因此，人们可能会保留历史上不同时间点的一系列快照存储库，但这不正是源代码控制的最初目的吗？ 直到有人发明了分布式模型，这个问题才存在。
Git 积极鼓励人们重写历史，上述可能就是原因之一。 每个普通的 VCS 都使得除了管理员之外的所有人都无法重写历史记录，并确保管理员没有理由考虑它。 如果我错了，请纠正我，但据我所知，git 没有提供任何方法来授予普通用户写入权限，但禁止他们重写历史记录。 这意味着任何怀有怨恨的开发人员（或者仍在努力应对学习曲线的开发人员）都可能会破坏整个代码库。 我们如何收紧这一点？ 好吧，要么定期备份整个历史记录，即保持历史记录的平方，要么禁止对所有内容进行写访问，除了一些可怜的草皮，他们会通过电子邮件接收所有差异并手动合并它们。
让我们举一个资金充足的大型项目的例子，看看 git 如何为他们工作：Android。 我曾经决定尝试一下android系统本身。 我发现我应该使用一堆名为 repo 的脚本来获取他们的 git。 一些 repo 运行在客户端上，一些运行在服务器上，但是两者的存在都说明了 git 在这两种能力上都是不完整的。 发生的事情是，我在大约一周内无法获取源代码，然后完全放弃了。 我必须从几个不同的存储库中提取大量数据，但服务器因像我这样的人而完全超载。 Repo 超时，无法从超时位置恢复。 如果 git 如此可分发，您可能会认为他们会做某种点对点的事情来减轻该一台服务器上的负载。 Git 是可分发的，但它不是服务器。 Git+repo 是一个服务器，但 repo 不可分发，因为它只是一个临时的 hack 集合。
git 的不足之处的一个类似例子是 gitolite （及其祖先，显然效果不太好。） Gitolite 将其工作描述为简化 git 服务器的部署。 再次，这个东西的存在证明了 git 不是服务器，也不是客户端。 更重要的是，它永远不会，因为如果它发展成任何一个，那就背叛了它的基本原则。
即使你确实相信分布式的东西，git 仍然会是一团糟。 例如，什么是分支机构？ 他们说每次克隆存储库时都会隐式创建一个分支，但这与单个存储库中的分支不同。 因此，至少有两种不同的事物被称为分支。 但是，您也可以在存储库中倒回并开始编辑。 这是否像第二种类型的分支，或者又是不同的东西？ 也许这取决于你拥有什么类型的回购协议 - 哦，是的 - 显然回购协议也不是一个非常清晰的概念。 有普通的和裸露的。 您无法推送到正常的部分，因为裸露的部分可能与其源树不同步。 但你不能 cvsimport 到一个裸机，因为他们没有想到这一点。 因此，您必须将 cvsimport 到一个普通的副本，将其克隆到开发人员点击的裸副本，然后将其 cvsexport 到仍需要签入 cvs 的 cvs 工作副本。 谁能被打扰呢？ 所有这些并发症从何而来？ 来自分布式思想本身。 我最终放弃了 gitolite，因为它对我施加了更多的限制。
Git 说分支应该是轻量级的，但许多公司已经存在严重的流氓分支问题，所以我认为分支应该是一个具有严格监管的重大决定。 这就是 perforce 真正闪耀的地方...
在 perforce 中，您很少需要分支，因为您可以以非常敏捷的方式处理变更集。 例如，通常的工作流程是同步到主线上最后一个已知的良好版本，然后编写您的功能。 每当您尝试修改文件时，该文件的差异都会添加到您的“默认变更集”中。 当您尝试签入变更集时，它会自动尝试将主线中的新闻合并到您的变更集中（有效地重新调整基础），然后提交。 这个工作流程是在您不需要理解的情况下强制执行的。 因此，主线收集了变化的历史记录，您可以在以后轻松地选择自己的方式。 例如，假设您想要恢复旧的，例如前一个之前的那个。 您同步到有问题的更改之前的时刻，将受影响的文件标记为变更集的一部分，同步到之后的时刻并与“始终是我的”合并。 （那里有一些非常有趣的事情：同步并不意味着拥有相同的东西 - 如果文件是可编辑的（即在活动变更集中），它不会被同步破坏，而是被标记为到期解析。）现在你有了撤销有问题的变更列表。 合并到后续新闻中，您将获得一个更改列表，您可以将其放在主线顶部以获得所需的效果。 我们在任何时候都没有改写任何历史。
现在，假设在这个过程进行到一半时，有人跑到你面前并告诉你放下一切并修复一些错误。 您只需为默认更改列表指定一个名称（实际上是一个数字），然后“暂停”它，修复现在空的默认更改列表中的错误，提交它，然后恢复指定的更改列表。 当您尝试不同的事情时，通常会暂停多个变更列表。 这既简单又私密。 你可以从分支政权中得到你真正想要的东西，而不会受到拖延的诱惑，也不会因为合并到主线而犹豫不决。
我想理论上可以在 git 中做类似的事情，但 git 几乎使一切成为可能，而不是断言我们认可的工作流程。 相对于分布式模型，集中式模型是一系列有效的简化，而分布式模型是无效的概括。 它过于笼统，基本上希望您在其之上实现源代码控制，就像 repo 那样。
另一件事是复制。 在 git 中，一切皆有可能，所以你必须自己解决。 实际上，您将获得有效的无状态缓存。 它需要知道的唯一配置是主服务器在哪里，客户端可以自行决定指向主服务器或缓存。 这是一个五分钟的工作，而且不会出错。
您还拥有用于断言代码审查、bugzilla 引用等的触发器和可自定义表单，当然，您还可以在实际需要时使用分支。 它不是很清晰，但很接近，并且非常容易设置和维护。
总而言之，我认为，如果您知道自己将以集中的方式工作（每个人都这样做），那么您不妨使用专门为此设计的工具。 Git 被高估是因为 Linus 的可怕智慧以及人们像绵羊一样互相追随的倾向，但它的主要存在理由实际上并不符合常识，通过追随它，git 束缚了自己的手脚。两个巨大的教条是（a）软件和（b）客户端和服务器上的数据必须相同，这总是会使集中式工作变得复杂和蹩脚。
Here's what I don't like about git:
First of all, I think the distributed idea flies in the face of reality. Everybody who's actually using git is doing so in a centralised way, even Linus Torvalds. If the kernel was managed in a distributed way, that would mean I couldn't actually download the "official" kernel sources - there wouldn't be one - I'd have to decide whether I want Linus' version, or Joe's version, or Bill's version. That would obviously be ridiculous, and that's why there is an official definition which Linus controls using a centralised workflow.
If you accept that you want a centralised definition of your stuff, then it becomes clear that the server and client roles are completely different, so the dogma that the client and server softwares should be the same becomes purely limiting. The dogma that the client and server data should be the same becomes patently ridiculous, especially in a codebase that's got fifteen years of history that nobody cares about but everybody would have to clone.
What we actually want to do with all that old stuff is bung it in a cupboard and forget that it's there, just like any normal VCS does. The fact that git hauls it all back and forth over the network every day is very dangerous, because it nags you to prune it. That pruning involves a lot of tedious decisions and it can go wrong. So people will probably keep a whole series of snapshot repos from various points in history, but wasn't that what source control was for in the first place? This problem didn't exist until somebody invented the distributed model.
Git actively encourages people to rewrite history, and the above is probably one reason for that. Every normal VCS makes rewriting history impossible for all but the admins, and makes sure the admins have no reason to consider it. Correct me if I'm wrong, but as far as I know, git provides no way to grant normal users write access but ban them from rewriting history. That means any developer with a grudge (or who was still struggling with the learning curve) could trash the whole codebase. How do we tighten that one? Well, either you make regular backups of the entire history, i.e. you keep history squared, or you ban write access to all except some poor sod who would receive all the diffs by email and merge them by hand.
Let's take an example of a well-funded, large project and see how git is working for them: Android. I once decided to have a play with the android system itself. I found out that I was supposed to use a bunch of scripts called repo to get at their git. Some of repo runs on the client and some on the server, but both, by their very existence, are illustrating the fact that git is incomplete in either capacity. What happened is that I was unable to pull the sources for about a week and then gave up altogether. I would have had to pull a truly vast amount of data from several different repositories, but the server was completely overloaded with people like me. Repo was timing out and was unable to resume from where it had timed out. If git is so distributable, you'd have thought that they'd have done some kind of peer-to-peer thing to relieve the load on that one server. Git is distributable, but it's not a server. Git+repo is a server, but repo is not distributable cos it's just an ad-hoc collection of hacks.
A similar illustration of git's inadequacy is gitolite (and its ancestor which apparently didn't work out so well.) Gitolite describes its job as easing the deployment of a git server. Again, the very existence of this thing proves that git is not a server, any more than it is a client. What's more, it never will be, because if it grew into either it would be betraying it's founding principles.
Even if you did believe in the distributed thing, git would still be a mess. What, for instance, is a branch? They say that you implicitly make a branch every time you clone a repository, but that can't be the same thing as a branch in a single repository. So that's at least two different things being referred to as branches. But then, you can also rewind in a repo and just start editing. Is that like the second type of branch, or something different again? Maybe it depends what type of repo you've got - oh yes - apparently the repo is not a very clear concept either. There are normal ones and bare ones. You can't push to a normal one because the bare part might get out of sync with its source tree. But you can't cvsimport to a bare one cos they didn't think of that. So you have to cvsimport to a normal one, clone that to a bare one which developers hit, and cvsexport that to a cvs working copy which still has to be checked into cvs. Who can be bothered? Where did all these complications come from? From the distributed idea itself. I ditched gitolite in the end because it was imposing even more of these restrictions on me.
Git says that branching should be light, but many companies already have a serious rogue branch problem so I'd have thought that branching should be a momentous decision with strict policing. This is where perforce really shines...
In perforce you rarely need branches because you can juggle changesets in a very agile way. For instance, the usual workflow is that you sync to the last known good version on mainline, then write your feature. Whenever you attempt to modify a file, the diff of that file gets added to your "default changeset". When you attempt to check in the changeset, it automatically tries to merge the news from mainline into your changeset (effectively rebasing it) and then commits. This workflow is enforced without you even needing to understand it. Mainline thus collects a history of changes which you can quite easily cherry pick your way through later. For instance, suppose you want to revert an old one, say, the one before the one before last. You sync to the moment before the offending change, mark the affected files as part of the changeset, sync to the moment after and merge with "always mine". (There was something very interesting there: syncing doesn't mean having the same thing - if a file is editable (i.e. in an active changeset) it won't be clobbered by the sync but marked as due for resolving.) Now you have a changelist that undoes the offending one. Merge in the subsequent news and you have a changelist that you can plop on top of mainline to have the desired effect. At no point did we rewrite any history.
Now, supposing half way through this process, somebody runs up to you and tells you to drop everything and fix some bug. You just give your default changelist a name (a number actually) then "suspend" it, fix the bug in the now empty default changelist, commit it, and resume the named changelist. It's typical to have several changelists suspended at a time where you try different things out. It's easy and private. You get what you really want from a branch regime without the temptation to procrastinate or chicken out of merging to mainline.
I suppose it would be theoretically possible to do something similar in git, but git makes practically anything possible rather than asserting a workflow we approve of. The centralised model is a bunch of valid simplifications relative to the distributed model which is an invalid generalisation. It's so overgeneralised that it basically expects you to implement source control on top of it, as repo does.
The other thing is replication. In git, anything is possible so you have to figure it out for yourself. In perforce, you get an effectively stateless cache. The only configuration it needs to know is where the master is, and the clients can point at either the master or the cache at their discretion. That's a five minute job and it can't go wrong.
You've also got triggers and customisable forms for asserting code reviews, bugzilla references etc, and of course, you have branches for when you actually need them. It's not clearcase, but it's close, and it's dead easy to set up and maintain.
All in all, I think that if you know you're going to work in a centralised way, which everybody does, you might as well use a tool that was designed with that in mind. Git is overrated because of Linus' fearsome wit together with peoples' tendency to follow each other around like sheep, but its main raison d'etre doesn't actually stand up to common sense, and by following it, git ties its own hands with the two huge dogmas that (a) the software and (b) the data have to be the same at both client and server, and that will always make it complicated and lame at the centralised job.
使用 GIT 来替代糟糕的代码行管理是很常见的。 Perforce 的许多缺点都是由于糟糕的分支策略造成的。 对于任何其他中心化工具来说都是如此。 如果您必须创建大量分支，那么您就做错了。 为什么开发者需要创建这么多分支？
另外，为什么离线工作如此重要？ 就这样有人可以在火车上工作吗？ 这几乎是目前唯一无法获得无线连接的地方。 甚至大多数火车都有不错的 WiFi。
Using GIT as substitute for bad code line management is common. Many of the disadvantages of Perforce are a result of bad branching strategies. The same for any other centralized tool. If you have to create a ton of branches you are doing something wrong. Why do developers need to create so many branches?
Also, why is working disconnected so important anyway? Just so someone can work on a train? That's about the only place these days you can't get a wireless connection. And even most trains have decent WiFi.
我在工作中使用 Perforce。 我还使用 Git，因为当我处理代码并且无法连接到服务器时，我仍然希望某种形式的版本控制。 不，协调离线工作只是不一样。 我发现 git 的一个很大的好处是：
决定改变您选择的平台，使用 Perforce，您将处于
Perforce.com 的仁慈以及工具的可用性
您选择的平台。
更改您用于源代码控制的内容，提取源代码
从 Perforce 控制历史并将其移至新系统 X 是
这将是一场噩梦，因为它是闭源的，而且是最好的
能做的就是猜测——只需 Google for Perforce 到 Git 的迁移即可获得
对我正在谈论的内容的感觉。 至少对于 Git 来说，它是开放的
来源，因此它消除了很多涉及的猜测。
嗯，这就是我的 2 美分。 在 Perforce 的辩护中，我必须说他们的客户支持规则以及他们的延时视图工具也是如此。 我不知道如何使用 git 获得延时视图。 但为了方便和节省时间，我随时都会选择 git。
I use Perforce at work. I also use Git because I would still like some form of version control when I'm working on code and can't connect to the server. No, reconcile offline work just is not the same. Here is where I've found git to be a great benefit:
decide to change your platform of choice, with Perforce, you're at
the mercy of Perforce.com and the availability of the tools for the
platform of your choosing.
to change what you use for source control, extracting your source
control history from Perforce and moving it to new system X is
going to be a nightmare, because it is closed source and the best you
can do is guess - just Google for Perforce to Git migration to get
a sense of what I'm talking about. At least with Git, its open
source, so it eliminates a lot of the guesswork involved.
Well, that's my 2 cents. In Perforce's defense, I gotta say their customer support rules and so does their Time Lapse View tool. I do not know how to get a time lapse view with git. But for the convenience and time saved, I'd go with git any day.
Perl 5 解释器源代码目前正在经历从 Perforce 转换为 git 的阵痛。 也许 Sam Vilain 的
git-p4raw导入器感兴趣。无论如何，与所有集中式 VCS 和大多数分布式 VCS 相比，您将获得的主要优势之一也是原始的、极快的速度。 在您亲自体验之前，您无法想象手边掌握整个项目历史（仅几分之一秒）是多么轻松。 即使生成整个项目历史记录的提交日志（其中包括每次提交的完整差异）也可以在几分之一秒内进行测量。 Git 太快了，你的帽子都会飞掉。 必须通过网络往返的 VCS 根本没有竞争的机会，甚至在千兆位以太网链路上也是如此。
此外，git 使得在提交时仔细选择变得非常容易，从而允许工作副本（甚至在单个文件内）中的更改分布在多个提交上 - 如果需要的话，还可以分布在不同的分支上。 这可以让您在工作时在心里记下更少的笔记——您不需要如此仔细地计划您的工作，预先决定您将进行哪些更改并确保推迟其他任何事情。 您可以根据自己的想法进行任何更改，并且在需要提交时仍然可以轻松地理清它们（几乎总是很容易）。 存储区在这里可以提供很大的帮助。
我发现，这些事实使我自然地比使用 git 之前做出更多、更集中的提交。 这不仅使您的历史记录更加有用，而且对于增值工具（例如
git bisect。我确信还有更多我现在想不到的事情。 在 git 上推销你的团队这一主张的一个问题是，正如我上面暗示的那样，许多好处是相互关联的并且相互抵消的，因此很难简单地查看 git 的功能和好处列表并推断出它们是如何发挥作用的。将改变您的工作流程，而哪些改变将是真正的改进。 你需要考虑到这一点，也需要明确指出这一点。
The Perl 5 interpreter source code is currently going through the throes of converting from Perforce to git. Maybe Sam Vilain’s
git-p4rawimporter is of interest.In any case, one of the major wins you’re going to have over every centralised VCS and most distributed ones also is raw, blistering speed. You can’t imagine how liberating it is to have the entire project history at hand, mere fractions of fractions of a second away, until you have experienced it. Even generating a commit log of the whole project history that includes a full diff for each commit can be measured in fractions of a second. Git is so fast your hat will fly off. VCSs that have to roundtrip over the network simply have no chance of competing, not even over a Gigabit Ethernet link.
Also, git makes it very easy to be carefully selective when making commits, thereby allowing changes in your working copy (or even within a single file) to be spread out over multiple commits – and across different branches if you need that. This allows you to make fewer mental notes while working – you don’t need to plan out your work so carefully, deciding up front what set of changes you’ll commit and making sure to postpone anything else. You can just make any changes you want as they occur to you, and still untangle them – nearly always quite easily – when it’s time to commit. The stash can be a very big help here.
I have found that together, these facts cause me to naturally make many more and much more focused commits than before I used git. This in turn not only makes your history generally more useful, but is particularly beneficial for value-add tools such as
git bisect.I’m sure there are more things I can’t think of right now. One problem with the proposition of selling your team on git is that many benefits are interrelated and play off each other, as I hinted at above, such that it is hard to simply look at a list of features and benefits of git and infer how they are going to change your workflow, and which changes are going to be bonafide improvements. You need to take this into account, and you also need to explicitly point it out.
我需要很大的说服力才能改变这种做法。 在我使用的两家公司中，它已经足够了。 这些公司都拥有不同的办公室，但这些办公室都建立了充足的基础设施，因此不需要具有脱节/互不关联的功能。
您正在谈论多少开发人员的转变？
真正的问题是 - perforce 无法满足 git 可以提供的组织需求的原因是什么？ 同样，与 perforce 相比，git 有哪些弱点？ 如果您自己无法回答这个问题，那么在这里问是没有帮助的。 您需要为您的公司找到一个商业案例。 （例如，也许总体拥有成本较低（包括临时学习阶段的生产力损失、较高的管理成本（至少在最初）等）
我认为您面临着艰难的推销 - perforce 是一个相当不错的选择如果您尝试启动 pvcs 或 ssafe，那么尝试替换它是理所当然的。
It would take me a lot of convincing to switch from perforce. In the two companies I used it it was more than adequate. Those were both companies with disparate offices, but the offices were set up with plenty of infrastructure so there was no need to have the disjoint/disconnected features.
How many developers are you talking about changing over?
The real question is - what is it about perforce that is not meeting your organization's needs that git can provide? And similarly, what weaknesses does git have compared to perforce? If you can't answer that yourself then asking here won't help. You need to find a business case for your company. (e.g. Perhaps it is with lower overall cost of ownership (that includes loss of productivity for the interim learning stage, higher admin costs (at least initially), etc.)
I think you are in for a tough sell - perforce is a pretty good one to try to replace. It is a no brainer if you are trying to boot out pvcs or ssafe.
我认为，为了让人们在切换期间/之后保持快乐，需要尽早了解的一件事是本地分支在 Git 中的私密性，以及给予他们犯错误的自由度。 让他们所有人从当前代码中克隆一些私有分支，然后在那里疯狂地进行实验。 重命名一些文件、检入内容、合并另一个分支的内容、倒回历史记录、将一组更改重新设置为另一组更改的基础，等等。 展示即使是当地最严重的事故也不会对其同事造成任何后果。 您想要的是开发人员感到安全的情况，这样他们就可以更快地学习（因为 Git 的学习曲线很陡峭，这一点很重要），最终使他们作为开发人员更加高效。
当您尝试学习集中式工具时，显然您会担心犯一些错误，从而给存储库的其他用户带来问题。 仅对尴尬的恐惧就足以阻止人们进行尝试。 即使有一个特殊的“培训”存储库也无济于事，因为开发人员不可避免地会在生产系统中遇到他们在培训期间从未见过的情况，因此他们又会担心。
但 Git 的分布式特性消除了这一点。 你可以在本地分支机构尝试任何实验，如果出现严重错误，只需扔掉该分支机构，没有人需要知道。 由于您可以创建任何内容的本地分支，因此您可以复制您在真实的实时存储库中看到的问题，但不会有“破坏构建”或以其他方式出丑的危险。 一旦完成，您就可以检查所有内容，无需尝试将工作批量打包成整齐的小包。 因此，不仅是您今天花了四个小时进行的两个主要代码更改，还有您中途记住的构建修复，以及您在向同事解释某些内容时发现的文档中的拼写错误，等等。 如果由于项目正在改变方向而放弃了重大更改，您可以从分支中挑选构建修复和拼写错误，并毫无麻烦地保留它们。
I think in terms of keeping people happy during/ post switch over, one of things to get across early is just how private a local branch can be in Git, and how much freedom that gives them to make mistakes. Get them all to clone themselves a few private branches from the current code and then go wild in there, experimenting. Rename some files, check stuff in, merge things from another branch, rewind history, rebase one set of changes on top of another, and so on. Show how even their worst accidents locally have no consequences for their colleagues. What you want is a situation where developers feel safe, so they can learn faster (since Git has a steep learning curve that's important) and then eventually so that they're more effective as developers.
When you're trying to learn a centralised tool, obviously you will be worried about making some goof that causes problems for other users of the repository. The fear of embarrassment alone is enough to discourage people from experimenting. Even having a special "training" repository doesn't help, because inevitably developers will encounter a situation in the production system that they never saw during training, and so they're back to worrying.
But Git's distributed nature does away with this. You can try any experiment in a local branch, and if it goes horribly wrong, just throw the branch away and nobody needs to know. Since you can create a local branch of anything, you can replicate a problem you're seeing with the real live repository, yet have no danger of "breaking the build" or otherwise making a fool of yourself. You can check absolutely everything in, as soon as you've done it, no trying to batch work up into neat little packages. So not just the two major code changes you spent four hours on today, but also that build fix that you remembered half way through, and the spelling mistake in the documentation you spotted while explaining something to a colleague, and so on. And if the major changes are abandoned because the project is changing direction, you can cherry pick the build fix and the spelling mistake out of your branch and keep those with no hassle.
个人在 git 上卖给我的命令是 bisect。 我认为目前任何其他版本控制系统都没有提供此功能。
话虽这么说，如果人们习惯使用 GUI 客户端进行源代码控制，他们就不会对 git 留下深刻的印象。 目前唯一的全功能客户端是命令行。
The command that sold me on git personally was bisect. I don't think that this feature is available in any other version control system as of now.
That being said, if people are used to a GUI client for source control they are not going to be impressed with git. Right now the only full-featured client is command-line.
人们正在使用哪些 Perforce 功能？
我问，因为如果所有人都在做的是从中获取和放置命令行方面，git 已经涵盖了这一点，所有其他 RTS 也是如此。
What Perforce features are people using?
I ask because if all folks are doing is get and put from the command line, git has that covered, and so do all the other RTS.
显然 GitHub 现在向公司提供 git 培训课程。 引用他们的博客文章：
强调我的。
Apparently GitHub now offer git training courses to companies. Quoth their blog post about it:
Emphasis mine.
我已经使用Perforce很长时间了，最近我也开始使用GIT。 这是我的“客观”意见：
Perforce 功能：
GIT 功能：
总体而言，对于开源/分布式项目，我会始终推荐 GIT，因为它更像是 P2P 应用程序，每个人都可以参与开发。 例如，我记得当我使用 Perforce 进行远程开发时，我每周通过 1Mbps 链接同步一次 4GB 项目。 因此浪费了很多时间。 我们还需要设置 VPN 来做到这一点。
如果您有一家小公司并且 P4 服务器始终处于运行状态，那么我会说 Perforce 也是一个非常好的选择。
I have been using Perforce for a long time and recently I also started to use GIT. Here is my "objective" opinion:
Perforce features:
GIT features:
Overall for OpenSource/Distributed projects I would always recommend GIT, because it is more like a P2P application and everyone can participate in development. For example, I remember that when I was doing remote development with Perforce I was syncing 4GB Projects over 1Mbps link once in a week. Alot of time was simply wasted because of that. Also we needed set up VPN to do that.
If you have a small company and P4 server will be always up then I would say that Perforce is also a very good option.