将 Git 与 ClearCase、AccuRev 或 Perforce 结合使用的价值？
我对将传统 SCM 产品（ClearCase、AccuRev、Perforce 等）与 Git 一起用于分布式团队的大型项目的价值（或缺乏价值）感兴趣。
提高团队活动的可见性是否会带来显着的增值？控制分支和合并？访问控制和安全？发布工程？其他因素？
还是 Git 本身更好？或者是否有一个开源的SCM可以与上面提到的商业产品等效？
谢谢。
I am interested in the value (or lack thereof) of using a traditional SCM product (ClearCase, AccuRev, Perforce, etc.) along with Git for large projects with distributed teams.
Is there a significant value-add in terms of increased visibility into team activities? Control of branching and merging? Access control and security? Release engineering? Other factors?
Or is it better to Git by itself? Or is there an open source SCM that would be equivalent to the commercial products mentioned above?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用尽可能少的系统。如果您没有看到单独使用 git 以外的任何东西的优势，那么就单独使用 git 吧。
大多数项目只使用一个 VCS（例如 git 或 Subversion），并且可以完成他们需要做的一切（分支，..），因此除非您有一个不寻常的需求，否则您可以非常确定一个产品可以完成所有工作你需要。
Use as few systems as you can get away with. If you don't see an advantage in using anything other than git alone, then just use git alone.
Most projects use just one VCS (e.g. git or Subversion) and can do everything they need to do (branching, ..) so unless you have a requirement you know of which is unusual, you can be pretty certain that one product will do everything you need.
我目前不希望将 Git 与 ClearCase 或 SVN 集成，主要是因为 Git 存储库无法保留与传统集中式存储库相同类型的数据（二进制文件）或卷（文件数量/大小）。
请参阅“Git 限制是什么？”。
我现在正尝试在企业 ClearCase-SVN 环境中引入 Git，作为独立的替代方案。
虽然速度、私有提交和合并功能非常受赞赏，但我被要求解决以下方面的实际问题：
prereceive挂钩，以便至少使用正确的user.name 进行一次提交配置（即user.name等于我们公司LDAP 中的通用名称cn）。 （有点像 gitolite 脚本 'contrib/update .email-check'，但用于user.name，而不是电子邮件）。但使用 ssh 私钥/公钥也意味着拥有带有密码短语的私钥（根据我们的安全团队的规定，这是强制性的），这对于与 Hudson 或其他工具集成来说并非易事。
简而言之，我仍然发现 Git 更好，但由于我负责实现其安装/管理，我完全同意我之前在 SO 问题“我们最终能否在企业软件中迁移到 DVCS？是SVN 仍然是开发的“必备”吗？”;)。
Integrating Git with ClearCase or SVN isn't something I am looking for at the moment, mainly because a Git repo cannot keep the same kind of data (binaries) or volume (number/size of files) than traditional centralized repos.
See "What are the Git limits?".
I am trying to introduce Git right now in a corporate ClearCase-SVN environment, as a stand-alone alternative.
While the speed, private commits and merge features are very much appreciated, I am asked to solve real issues in term of:
prereceivehooks in order to have at least one commit made with the rightuser.nameconfig (i.e. auser.nameequals to the common namecnin the LDAP of our company). (a bit like the gitolite script 'contrib/update.email-check', but foruser.name, not for email).But using ssh private/public keys also means having private keys with pass-phrase (mandatory according to our security team), and that isn't trivial to integrate with Hudson or other tools.
In short, I still find Git better, but since I am in charge of implementing its installation/administration, I fully agree with my previous analysis made in the SO question "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?" ;).
有价值。
使用廉价本地分支的灵活性和便利性来促进本地（计算机）环境中的开发人员工作流程，使用集中式系统轻松控制基于角色的权限和大量文件的聚合。
开发人员基于任务的分支保留在分布式系统中，并保持集中式历史记录更清晰。
集中式系统可用于从分布式系统卸载大型二进制资产。
有成本。
混合环境的支持/培训。
需要在系统之间定位/维护转换层。
There is value.
Use flexibility and convenience of cheap local branching to facilitate developer work flow in your local (machine) environment, use the centralized system for easy control of role based permissions and conglomeration of large numbers of files.
Developer task-based branching stays in the distributed system and keeps centralized history cleaner.
Centralized systems can be used to off load large binary assets from distributed systems.
There is cost.
Supporting/training for a hybrid environment.
Requires locating/maintaining a translation layer between systems.