在您的公司使用 git（或其他一些 VCS）
我和我的一些朋友最近正在谈论版本控制，以及他们如何在工作中使用 VSS，并且可能很快就会放弃这些。其中一位表示，他的公司可能会使用 Team Foundation Server。
最终，谈话确实开始讨论一些开源 VCS，包括 git 和 SVN。我们没有人真正了解任何在内部使用这些工具的公司，尽管我们想象其中一些公司是为 SVN 这样做的，但我们对 git 不太确定。我提到了 Google 和 Android 使用它，但我的朋友认为这仅适用于面向公众的源代码，他们可能会在内部项目中使用不同的东西。
显然，不仅仅是 SCM 使 TFS 如此有趣：
- Microsoft 销售人员和支持（尽管我的朋友确实向他的经理指出了一些他认为 MS 方面可能会产生误导的内容）
- SCM 之外的事物的集成，包括项目管理（我的朋友）我只是发现 git 也有同样的东西）
- 同样，这是 Microsoft，从 VSS 到 TFS 的过渡似乎是合乎逻辑的（或者确实如此？）
我不太喜欢 SVN，所以我没有其实没怎么提，但我很好奇你们公司内部项目是否使用git。
你有没有想过，并决定不这样做？有什么理由吗？
Some friends of mine and I were talking recently about version control, and how they were using VSS at their jobs, and were probably going to be moving off of that soon. One of them said that his company will likely be going with Team Foundation Server.
Eventually, the conversation did get around to talking about some of the open source VCSes out there, including git and SVN. None of us really knew about any companies that use either of these internally, although we imagined that a number of them did so for SVN, but we weren't too sure about git. I brought up Google and Android using it, but my friend figured that's only for the public facing source code, and that they may use something different for internal projects.
Apparently it's more than just SCM that makes TFS so intriguing:
- Microsoft Sales people and support (although my friend did point out somethings to his managers that he thought might be misleading on MS' part)
- Integration of things beyond SCM, including project management (I'm just finding out that there are geared towards the same things for git)
- Again, it's Microsoft, and the transition from VSS to TFS seems logical (or does it?)
I'm not much of a fan of SVN, so I didn't really bring it up much, but I am curious about whether or not git is used at your company for internal projects.
Have you thought about it, and decided against it? Any reason why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我们所有的源代码都使用 git。这很有道理。
理论上这些商业系统应该可以在它们的支持下将您从损坏的存储库中拯救出来并提供各种美妙的东西。
在实践中，我在集中式存储库上损失的代码和时间比分布式存储库多。
We use git for all of our source code. It just makes sense.
In theory these commercial systems should save you from broken repositories and all kinds of wonderful things with their support.
In practice I've lost more code and time to centralized repositories than distributed.
该问题应该是社区维基，并且是主观的。
在我看来，这都是关于整合的。 TFS不仅仅是直接的版本控制，而且集成得很好吗？进入 MS 堆栈。如果您是 MS House，那么这是一个合理的选择。
开源理念表示采用“过滤器”或“可重用的小型组件”方法来设计系统...以及系统的系统...如果您想替换 TFS 或其他一些解决方案，那么您需要将 SVN、git 或任何其他 VCS 集成到您的解决方案中。
MS 的产品可立即用于 MS 系列产品。使用开源，您可以选择......但您很可能需要将其集成到其他东西（例如 bugzilla）中以获得类似的解决方案。选择是好的；但这取决于您的公司是否从事为客户开发软件或花费时间和金钱开发内部解决方案的业务。
The question should be a community wiki, and is subjective.
It seems to me this is all about integration. TFS is more than just straight version control, and is integrated well? into the MS stack. If you are an MS house then it is a logical choice.
open-source philosophy denotes a 'filter' or 're-usable, small components' approach to designing systems ... and systems of systems ... if you wanted to replace TFS or some other solution, then you would need to integrate SVN, git or any other VCS into your solution.
MS stuff works out of the box for an MS range of products. With open source, you have choice ... but you may well need to integrate it into other things (like bugzilla) to get a comparable solution. The choice is good; but it depends if your company is in the business of developing software for customers or spending time and money rolling in-house solutions.
基本上，当将重要代码存储到存储库时，企业会特别考虑一点：
当存储库崩溃、以任何方式损坏或需要分析时，它可以从所使用的 VCS 背后的公司获得什么样的支持？< br>
是否有附带的 SLA（服务级别协议）？
您很少会使用开源产品，并且您并不总是需要它（因为您可以访问几乎所有的开源产品）
并且在开始之前还需要考虑其他方面“与其他工具集成”部分：
所有这些点可以影响商业或开源解决方案的决策。
编辑：仅供参考，我刚刚在 CM （配置管理，pdf文件） 其中有一些支持或反对商业工具的很好的论据。 （7.4 一般讨论，第 98-99 页）
注：以上并不是“绝对”的事实，可能会找到一些反例，但我相信一般性的论证有其可取之处，我将其添加在这里供其他人查看。
Basically, when storing important code into repository, an enterprise will consider one point in particular:
What kind of support can it expect from the company behind the VCS used, when the repository crashed, becomes corrupted in any way or need to be analyzed?
Is there a SLA (Service Level Agreement) which comes with it.
You will rarely have that with open-source product, and you do not always need it (since you have access to pretty much all the -- open-source- product)
And there are other aspects to consider as well, before even coming to the "integration with other tools" part:
All of those points can influence the decision in favor of a commercial or an open-source solution.
Edit: just for information, I just found this these on CM (Configuration management, pdf file) which has some good arguments for or against a commercial tool. (7.4 General discussion, pages 98-99)
Note: the above is not an "absolute" truth, and some counter-example might be found, but I believe the general argument has its merit and I add it here for others to see.
我认为 git 和 DVCS 的开发理念总体上对大公司没有吸引力——中央存储库对他们来说更有意义（实际上可能更适合集中式组织）。
我在一家大型银行IT服务公司工作；他们仅在两年前从 CVS 迁移到 SVN，采取了明显的升级路径。
I don't think the development philosophy of git and DVCS in general is appealing to larger companies - a central repository makes much more sense to them (and may in fact actually work better for centralized organizations).
I work for a large IT service company in the banking sector; they migrated from CVS to SVN only 2 years ago, taking the obvious upgrade path.
作为一名顾问，我曾在几个使用 Subversion 作为源代码控制系统的客户（一些相当大的公司，如 Baker Hughes）工作过（请注意，有些团队使用 TFS）。我什至在以前的雇主那里使用过它（从 VSS 切换到 SVN）。
就 Git 而言，我还没有看到太多公司在内部使用它，并且我怀疑您会这样做，直到有更好的 Windows 界面。我听说像 Git Extensions 和 TortoiseGit 这样的东西正在变得越来越好，而且我听说有人使用这些工具取得了巨大成功，但他们并没有在大公司使用它们。
As a consultant I've worked at several clients (some rather large names like Baker Hughes) that use Subversion as their source control system (note some teams were on TFS). I even used it at a previous employer (switched from VSS to SVN).
As far as Git goes, I have not seen too many companies using it internally yet and I doubt you will until there are better Windows interfaces for it. I have heard that things like Git Extensions and TortoiseGit are getting a lot better and I have heard of people having great success with those tools but they weren't using them at a large company.
许多公司使用 Mercurial、Git 或 SVN 等开源工具。在我工作的地方，我们几乎只使用 SVN，几年前我们就不再使用 ClearCase。
其中许多工具比商业竞争对手更简单、更轻量、更可配置且支持更好。此外，许多新员工在开源工作或在学校工作时已经熟悉了 Mercurial、Git，甚至 Subversion。你真的不能指望每个用户花费 4000 美元的软件能有同样的效果。
如果您担心支持问题，有些公司通过支持（和托管）开源版本控制来开展业务。我正在考虑雾溪窑，Atlassian（拥有 BitBucket），当然还有 GitHub 在较小程度上（有没有想过谁真正购买了多用户付费 GitHub 计划？是的……企业也使用 git。）
Plenty of companies use open-source tools like Mercurial, Git, or SVN. Where I work we use SVN almost exclusively, we moved off ClearCase a few years ago.
A lot of these tools are easier, more lightweight, more configurable, and better supported than their commercial competitors. Additionally, many new hires will already be familiar with Mercurial, Git, and even Subversion from working in open source or at school. You really can't expect the same from software that costs $4000 per user.
If you're worried about support, there are companies who make a business out of supporting (and hosting) open-source version control. I'm thinking about Fog Creek's Kiln, Atlassian (who own BitBucket), and of course GitHub to a smaller extent (ever wonder who actually buys multi-user paid GitHub plans? Yeah...businesses use git, too.)
我曾在许多不同的公司担任过开发人员（短期合同和长期雇佣）。自 2009 年左右以来，我所做的每一份工作都使用了 Git（在此之前我使用过 SVN 和 CVS）。此时我不会再回到非分布式 VCS。
I've worked as a developer at a lot of different companies (short-term contracts and longer employment). Every job I've had since about 2009 has used Git (I used SVN and CVS before that). I wouldn't go back to a non-distributed VCS at this point.
的公司合作
这是我的数据点：在过去的十年中，我与大致按顺序 。多年来，一些公司使用了其中的几个（我建议并执行了一些转换），其中一家公司在我离开时从 SVN 切换到 git，首先将其用于他们作为开源发布的库。
Here's my data point: In the last decade, I have worked with companies that used
roughly in that order. Some companies used several of these over the years (I have suggested and performed some of the transitions), the one company that switched from SVN to git did so when I was leaving, first using it for a library they released as Open Source.