Git 与 Team Foundation Server
我向我的开发团队介绍了 Git，但每个人都讨厌它，除了我。他们想要取代 与 Team Foundation Server 一起使用。我觉得这是一个巨大的倒退，尽管我对 TFS 不是很熟悉。有经验的人可以比较 TFS 和 Git 分支的分支支持吗？另外，一般来说，TFS 的优点和缺点是什么？以后我会讨厌吗 使用 Git 几年了？
I introduced Git to my dev team, and everyone hates it except me. They want to replace
it with Team Foundation Server. I feel like this is a huge step backwards, although I am not very familiar with TFS. Can someone with experience compare branching support on TFS to Git branching? Also, in general, what are the pros and cons of TFS? Am I going to hate it after
using Git for a few years?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为，声明
任何进一步的讨论都浪费了：当你继续使用 Git 时，如果出现任何问题，他们会责怪你。
除此之外，对我来说，Git 相对于集中式 VCS 有两个我最欣赏的优势（如 Rob Sobers）：
但正如我所说：我认为你正在打一场失败的仗：当每个人都讨厌 Git 时，就不要使用 Git。它可以帮助你更多地了解为什么他们讨厌 Git，而不是试图说服他们。
如果他们只是不想要它，因为这对他们来说是新的，并且不愿意学习新东西：你确定你会与该员工一起成功开发吗？
真的每个人都讨厌 Git 还是他们受到某些意见领袖的影响？找到领导，问他们有什么问题。说服他们，你就能说服团队的其他成员。
如果你无法说服领导：别用 Git，采用 TFS。将使您的生活更轻松。
I think, the statement
makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
But as I said: I think that you're fighting a lost battle: when everyone hates Git, don't use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don't want it 'cause it's new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?
Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what's the problem. Convince them and you'll convince the rest of the team.
If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.
这两个系统之间的主要区别在于，TFS 是集中式版本控制系统，而 Git 是分布式版本控制系统。
使用 TFS，存储库存储在中央服务器上，开发人员可以签出工作副本，该副本是代码在特定时间点的快照。使用 Git，开发人员可以将整个存储库克隆到他们的计算机上，包括所有历史记录。
在开发人员的计算机上拥有完整存储库的好处之一是在服务器死机时提供冗余。另一个不错的好处是，您可以在修订版之间来回移动工作副本，而无需与服务器通信，如果服务器关闭或无法访问，这会很有帮助。
对我来说，真正的好处是您可以将更改集提交到本地存储库，而无需与服务器通信或对您的团队造成潜在的不稳定更改（即破坏构建）。
例如，如果我正在开发一个大功能，我可能需要一周的时间来对其进行编码和完全测试。我不想在周中签入不稳定的代码并破坏构建，但是如果我临近周末并且不小心破坏了整个工作副本，会发生什么？如果我没有一直做出承诺，我就有失去工作的风险。这不是有效的版本控制，TFS 很容易受到此影响。
借助 DVCS，我可以不断提交，而不必担心破坏构建，因为我是在本地提交更改。在 TFS 和其他集中式系统中，没有本地签入的概念。
我什至没有讨论 DVCS 中的分支和合并有多好，但是您可以在 SO 上或通过 Google 找到大量解释。我可以根据经验告诉你，TFS 中的分支和合并并不好。
如果您的组织中 TFS 的论点是它在 Windows 上比 Git 工作得更好，我建议使用 Mercurial，它在 Windows 上工作得很好——它与 Windows 资源管理器 (TortoiseHg) 和 Visual Studio (VisualHg) 集成。
The key difference between the two systems is that TFS is a centralized version control system and Git is a distributed version control system.
With TFS, repositories are stored on a central server and developers check-out a working copy, which is a snapshot of the code at a specific point in time. With Git, developers clone the entire repository to their machines, including all of the history.
One benefit of having the full repository on your developer's machines is redundancy in case the server dies. Another nice perk is that you can move your working copy back and forth between revisions without ever talking to the server, which can be helpful if the server is down or just unreachable.
To me, the real boon is that you can commit changesets to your local repository without ever talking to the server or inflicting potentially unstable changes on your team (i.e., breaking the build).
For instance, if I'm working on a big feature, it might take me a week to code and test it completely. I don't want to check-in unstable code mid-week and break the build, but what happens if I'm nearing the end of the week and I accidentally bork my entire working copy? If I haven't been committing all along I stand the risk of losing my work. That is not effective version control, and TFS is susceptible to this.
With DVCS, I can commit constantly without worrying about breaking the build, because I'm committing my changes locally. In TFS and other centralized systems there is no concept of a local check-in.
I haven't even gone into how much better branching and merging is in DVCS, but you can find tons of explanations here on SO or via Google. I can tell you from experience that branching and merging in TFS is not good.
If the argument for TFS in your organization is that it works better on Windows than Git, I'd suggest Mercurial, which works great on Windows -- there's integration with Windows Explorer (TortoiseHg) and Visual Studio (VisualHg).
人们需要放下枪，离开壁架，然后思考一分钟。事实证明，DVCS 具有客观、具体且不可否认的优势，可以极大地提高团队的生产力。
这一切都归结为分支和合并。
在 DVCS 之前，指导原则是“向上帝祈祷，让你不必进行分支和合并。如果你这样做，至少祈求他让事情变得非常非常简单。”
现在，有了 DVCS，分支（和合并）得到了很大的改进，指导原则是，“一下子就做这件事。它会给你带来很多好处，而且不会给你带来任何影响。”问题”。
这对于任何团队来说都是一个巨大的生产力提升器。
问题是，为了让人们理解我刚才所说的并确信这是真的，他们必须首先投资一点学习曲线。他们不必学习 Git 或任何其他 DVCS 本身……他们只需要学习 Git 如何进行分支和合并。阅读并重新阅读一些文章和博客文章，慢慢地阅读，直到你看到为止。这可能需要 2 到 3 天的时间。
但一旦看到这一点，您就不会考虑选择非 DVCS。因为 DVCS 确实有明显、客观、具体的优势，而且最大的优势在于分支和合并领域。
People need to put down the gun, step away from the ledge, and think for a minute. It turns out there are objective, concrete, and undeniable advantages to DVCS that will make a HUGE difference in a team's productivity.
It all comes down to Branching and Merging.
Before DVCS, the guiding principle was "Pray to God that you don't have to get into branching and merging. And if you do, at least beg Him to let it be very, very simple."
Now, with DVCS, branching (and merging) is so much improved, the guiding principle is, "Do it at the drop of a hat. It will give you a ton of benefits and not cause you any problems."
And that is a HUGE productivity booster for any team.
The problem is, for people to understand what I just said and be convinced that it is true, they have to first invest in a little bit of a learning curve. They don't have to learn Git or any other DVCS itself ... they just need to learn how Git does branching and merging. Read and re-read some articles and blog posts, taking it slow, and working through it until you see it. That might take the better part of 2 or 3 full days.
But once you see that, you won't even consider choosing a non-DVCS. Because there really are clear, objective, concrete advantages to DVCS, and the biggest wins are in the area of branching and merging.
原始：@Rob，TFS 有一个名为“搁置”，解决您对提交正在进行的工作而不影响官方构建的担忧。我知道您认为中央版本控制是一个障碍，但就 TFS 而言，将代码签入架子可以被视为一种优势，然后中央服务器在极少数情况下拥有您正在进行的工作的副本您的本地机器崩溃或丢失/被盗，或者您需要快速切换齿轮。我的观点是，TFS 在这方面应该得到适当的赞扬。另外，TFS2010 中的分支和合并功能较之前版本有所改进，当您说“……根据经验，TFS 中的分支和合并不好”时，不清楚您指的是哪个版本。免责声明：我是 TFS2010 的中等用户。
编辑 2011 年 12 月 5 日：对于 OP，TFS 让我烦恼的一件事是，当您不处理它们时，它坚持将所有本地文件设置为“只读”。如果要进行更改，流程是必须“签出”文件，这只是清除文件的只读属性，以便 TFS 知道要密切关注它。这是一个不方便的工作流程。我希望它的工作方式是自动检测我是否进行了更改，并且根本不用担心/打扰文件属性。这样，我就可以在 Visual Studio、记事本或任何我喜欢的工具中修改该文件。版本控制系统在这方面应该尽可能透明。有一个 Windows 资源管理器扩展 (TFS PowerTools)，允许您可以在 Windows 资源管理器中处理文件，但这并不能大大简化工作流程。
Original: @Rob, TFS has something called "Shelving" that addresses your concern about commiting work-in-progress without it affecting the official build. I realize you see central version control as a hindrance, but with respect to TFS, checking your code into the shelf can be viewed as a strength b/c then the central server has a copy of your work-in-progress in the rare event your local machine crashes or is lost/stolen or you need to switch gears quickly. My point is that TFS should be given proper praise in this area. Also, branching and merging in TFS2010 has been improved from prior versions, and it isn't clear what version you are referring to when you say "... from experience that branching and merging in TFS is not good." Disclaimer: I'm a moderate user of TFS2010.
Edit Dec-5-2011: To the OP, one thing that bothers me about TFS is that it insists on setting all your local files to "read-only" when you're not working on them. If you want to make a change, the flow is that you must "check-out" the file, which just clears the readonly attribute on the file so that TFS knows to keep an eye on it. That's an inconvenient workflow. The way I would prefer it to work is that is just automatically detects if I've made a change and doesn't worry/bother with the file attributes at all. That way, I can modify the file either in Visual Studio, or Notepad, or with whatever tool I please. The version control system should be as transparent as possible in this regard. There is a Windows Explorer Extension (TFS PowerTools) that allows you to work with your files in Windows Explorer, but that doesn't simplify the workflow very much.
最重要的是（
），
这是正确的，TFS 不仅仅是一个 VCS。 TFS 提供的一项主要功能是本机集成的错误跟踪功能。变更集与问题相关联并且可以被跟踪。支持各种签入策略，以及与 Windows 域的集成，这是运行 TFS 的人所拥有的。与 Visual Studio 紧密集成的 GUI 是另一个卖点，它吸引了
低于平均水平的鼠标和点击开发人员及其经理。因此，将 Git 与 TFS 进行比较并不是一个合适的问题。正确但不切实际的问题是将 Git 与 TFS 的 VCS 功能进行比较。此时，Git 将 TFS 彻底淘汰。然而，任何认真的团队都需要其他工具，而这正是 TFS 提供的一站式目的地。
On top of everything that's been said (
),
which is correct, TFS isn't just a VCS. One major feature that TFS provides is natively integrated bug tracking functionality. Changesets are linked to issues and could be tracked. Various policies for check-ins are supported, as well as integration with Windows domain, which is what people who run TFS have. Tightly integrated GUI with Visual Studio is another selling point, which appeals to
less than averagemouse and click developer and his manager.Hence comparing Git to TFS isn't a proper question to ask. Correct, though impractical, question is to compare Git with just VCS functionality of TFS. At that, Git blows TFS out of the water. However, any serious team needs other tools and this is where TFS provides one stop destination.
如果您的团队使用 TFS 并且您想使用 Git，您可能需要考虑“git 到 tfs”桥梁。本质上，您每天在计算机上使用 Git 进行工作，然后当您想要推送更改时，您可以将它们推送到 TFS 服务器。
那里有几个（在 github 上）。我在最后一个地方使用了一个（与另一位开发人员一起）并取得了一些成功。请参阅：
https://github.com/spraints/git-tfs
https://github.com/spraints/git-tfs com/git-tfs/git-tfs">https://github.com/git-tfs/git-tfs
If your team uses TFS and you want to use Git you might want to consider a "git to tfs" bridge. Essentially you work day to day using Git on your computer, then when you want to push your changes you push them to the TFS server.
There are a couple out there (on github). I used one at my last place (along with another developer) with some success. See:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
经过一番利弊考察后，我所在的公司也决定选择TFS。并不是因为 GIT 不是一个好的版本控制系统，而是最重要的是 TFS 提供的完全集成的 ALM 解决方案。如果只有版本控制功能很重要，那么选择可能就是 GIT。然而，对于普通开发人员来说，陡峭的 GIT 学习曲线可能不容低估。
请参阅我的博客文章中的详细说明 TFS 作为真正的交叉-技术平台。
After some investigation between the pro and cons, the company I was involved with also decided to go for TFS. Not because GIT isn't a good version control system, but most importantly for the fully integrated ALM solution that TFS delivers. If only the version control feature was important, the choice may probably have been GIT. The steep GIT learning curve for regular developers may however not be underestimated.
See a detailed explanation in my blog post TFS as a true cross-technology platform.
Git 的整个分布式功能真的非常棒。它提供了一些 Shelvesets 没有的功能（在当前产品中），例如本地回滚和提交选项（例如 Eclipse 的本地历史记录功能）。您可以使用开发人员分支来缓解这种情况，但说实话，许多开发人员不喜欢分支和合并。我经常被要求打开 TFS 中旧式的“独家结账”功能（并且每次都被拒绝）。
我认为许多大型企业都非常害怕允许开发人员将整个历史记录带入本地工作区并随身携带（例如新雇主）......窃取快照是不好的，但拿走整个历史记录就更麻烦了。 （并不是说您无法从 TFS 获取您想要的完整历史记录）...
有人提到这是一种很好的备份方式，这对于开源来说非常有用，原始维护者可能会停止关心并删除他的版本，但对于企业计划来说，这对于许多企业来说又是不够的，因为没有明确的责任分配来保留备份。如果主要“项目”以某种方式消失，则很难确定要使用哪个版本。这倾向于指定一个存储库作为主导/中心。
我最喜欢 Git 的是 Push/Pull 选项，您可以轻松地向项目贡献代码，而无需拥有提交权限。我想您可以在 TFS 中使用非常有限的用户和搁置集来模拟这一点，但它不如 Git 选项强大。跨团队项目分支也可能有效，但从管理角度来看，这对于许多组织来说并不可行，因为添加团队项目会增加大量管理开销。
我还想补充一下非源代码控制领域提到的内容。工作项跟踪、报告和构建自动化（包括实验室管理）等功能极大地受益于中央领先的存储库。当您使用纯分布式模型时，这些会变得更加困难，除非您使其中一个节点处于领先位置（从而返回到分布式程度较低的模型）。
随着 TFS Basic 随 TFS 11 一起推出，在 TFS 12+ 时代，分布式 TFS 允许您将本地 TFS basic 同步到中央 TFS 可能并不遥远。我将投下我的投票请在用户声音中注明！
The whole Distributed thing of Git is really really great. it gives a few features Shelvesets don't have (in the current product) such as local rollback and commit options (such as Eclipse's localhistory feature). You could alleviate this using developer branches, but lets be honest, many developers don't like branching and merging one bit. I've been asked to turn on the old style "exclusive checkout" feature in TFS a few times too often (and denied it each and every time).
I think many large enterprises are quite scared to allow a dev to just bring the whole history into a local workspace and take it with them (to a new employer for example)... Stealing a snapshot is bad, but taking away a whole history is even more troublesome. (Not that you couldn't get a full history from TFS of you wanted it)...
It's mentioned that it's a great way to backup, which is great for open source again where the original maintainer might stop to care and removes his version, but for a enterprise plan this again falls short for many enterprises as there is no clear assignment of responsibility to keep backups. And it would be hard to figure out which version to use if the main 'project' vanishes somehow. Which would tend to appoint one repository as leading/central.
What I like most about Git is the Push/Pull option, where you can easily contribute code to a project without the need to have commit rights. I guess you could use very limited users and shelvesets in TFS to mimic this, but it isn't as powerful as the Git option. Branching across team projects might work as well, but from an administrative perspective it's not really feasible for many organisations as adding team projects adds a lot of administartive overhead.
I'd also like to add to the things mentioned in the non source control area. Features such as Work Item Tracking, Reporting and Build Automation (including lab management) greatly benefit from a central leading repository. These become a lot harder when you use a pure distributed model, unless you make one of the nodes leading (and thus go back to a less distributed model).
With TFS Basic coming with TFS 11, it might not be far off to expect a distributed TFS which allows you to sync your local TFS basic to a central TFS in the TFS 12+ era. I'll put my vote for that down in the uservoice!
对我来说，主要区别是 TFS 将添加到您的解决方案 (.vssscc) 中以“支持”TFS 的所有辅助文件 - 我们最近遇到了这些文件最终映射到错误分支的问题，这导致了一些有趣的调试...
For me the major difference is all the ancilliary files that TFS will add to your solution (.vssscc) to 'support' TFS - we've had recent issues with these files ending up mapped to the wrong branch, which lead to some interesting debugging...