Git 与 Team Foundation Server

Git vs Team Foundation Server

提问by Hymano

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?

我向我的开发团队介绍了 Git，除了我之外，每个人都讨厌它。他们想用 Team Foundation Server 替换它。我觉得这是一个巨大的倒退，虽然我对 TFS 不是很熟悉。有经验的人可以将 TFS 上的分支支持与 Git 分支进行比较吗？另外，一般来说，TFS 的优缺点是什么？使用 Git 几年后我会讨厌它吗？

回答by eckes

I think, the statement

我认为，声明

everyone hates it except me

每个人都讨厌它，除了我

makes any further discussion waste: when you keep using Git, they will blame youif anything goes wrong.

浪费任何进一步的讨论：当您继续使用 Git 时，如果出现任何问题，他们会责怪您。

Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):

除此之外，对我来说，与我最欣赏的集中式 VCS 相比，Git 有两个优势（正如Rob Sobers部分描述的那样）：

• automatic backup of the whole repo:everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don't worry, take one of those present on every workstation.
• offline repo access:when I'm working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I wereat work: checkin, checkout, branch, anything.

• 整个 repo 的自动备份：每次有人从中央 repo 中提取时，他/她都会获得更改的完整历史记录。当一个 repo 丢失时：别担心，拿走每个工作站上的一个。
• 离线回购访问：当我在家里工作（或者在飞机或火车上），我可以看到这个项目，每一个签入的全部历史，不启动工作我的VPN连接，并能正常工作像我是在工作中: 签入，签出，分支，任何东西。

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 Gitinstead of trying them to convince them.

但正如我所说：我认为你正在打一场失败的战斗：当每个人都讨厌 Git 时，不要使用 Git。它可以帮助您更多地了解他们为什么讨厌 Git，而不是试图说服他们。

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.

真的每个人都讨厌 Git 还是受到某些意见领袖的影响？找到领导，问他们有什么问题。说服他们，你就会说服团队的其他成员。

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.

如果你不能说服领导者：忘记使用 Git，选择 TFS。会让你的生活更轻松。

回答by Rob Sobers

The key difference between the two systems is that TFS is a centralized version control system and Git is a distributed version control system.

两个系统的关键区别在于，TFS 是集中式版本控制系统，而 Git 是分布式版本控制系统。

With TFS, repositories are stored on a central server and developers check-out a working copy, which is a snapshotof the code at a specific point in time. With Git, developers clone the entire repositoryto their machines, including all of the history.

使用 TFS，存储库存储在中央服务器上，开发人员签出工作副本，这是特定时间点代码的快照。使用 Git，开发人员将整个存储库克隆到他们的机器上，包括所有历史记录。

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 commitchangesets 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.

例如，如果我正在开发一个大功能，我可能需要一周的时间来对其进行完整的编码和测试。我不想在周中签入不稳定的代码并破坏构建，但是如果我接近周末并且不小心把整个工作副本弄坏了怎么办？如果我一直没有承诺，我就有失去工作的风险。这不是有效的版本控制，TFS 很容易受到影响。

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.

使用 DVCS，我可以不断提交而不必担心破坏构建，因为我是在本地提交我的更改。在 TFS 和其他集中式系统中，没有本地签到的概念。

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.

我什至没有讨论 DVCS 中的分支和合并有多好，但是您可以在 SO 上或通过 Google 找到大量解释。我可以从经验中告诉你，TFS 中的分支和合并是不好的。

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).

如果您的组织中 TFS 的论点是它在 Windows 上比 Git 更有效，我建议 Mercurial，它在 Windows 上工作得很好——它与 Windows 资源管理器 (TortoiseHg) 和 Visual Studio (VisualHg) 集成。

回答by Charlie Flowers

People need to put down the gun, step away from the ledge, and thinkfor 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.

人们需要放下枪，离开窗台，思考一分钟。事实证明，DVCS 具有客观、具体和不可否认的优势，这将对团队的生产力产生巨大的影响。

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."

在 DVCS 之前，指导原则是“向上帝祈祷，你不必进入分支和合并。如果你这样做，至少求他让它非常非常简单。”

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."

现在，有了 DVCS，分支（和合并）得到了很大的改进，指导原则是，“轻而易举。它会给你带来很多好处，而不会给你带来任何问题。”

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.

问题是，为了让人们理解我刚才所说的并确信它是真实的，他们必须首先投资一点点学习曲线。他们不必学习 Git 或任何其他 DVCS 本身……他们只需要学习 Git 如何进行分支和合并。阅读并重新阅读一些文章和博客文章，慢慢来，通读一遍，直到看到为止。这可能需要 2 到 3 天的大部分时间。

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.

但是一旦看到这一点，您甚至不会考虑选择非 DVCS。因为 DVCS 确实有明确、客观、具体的优势，而最大的优势在于分支和合并领域。

回答by Lee Grissom

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.

原创：@Rob，TFS有一些所谓的“货架”，解决你关于commiting工作正在进行又不影响官方的构建问题。我意识到您认为中央版本控制是一个障碍，但是对于 TFS，将您的代码检查到架子中可以被视为一种优势 b/c 然后中央服务器在极少数情况下拥有您正在进行的工作的副本您的本地机器崩溃或丢失/被盗，或者您需要快速换档。我的观点是 TFS 在这方面应该得到适当的赞扬。此外，TFS2010 中的分支和合并已比以前的版本有所改进，当您说“......根据经验，TFS 中的分支和合并并不好”时，不清楚您指的是哪个版本。免责声明：我是 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.

2011 年 12 月 5 日编辑：对于 OP，让我困扰的关于 TFS 的一件事是，当您不使用它们时，它坚持将所有本地文件设置为“只读”。如果您想进行更改，流程是您必须“签出”文件，这只是清除文件上的只读属性，以便 TFS 知道要密切注意它。这是一个不方便的工作流程。我更喜欢它的工作方式是它只是自动检测我是否进行了更改并且根本不担心/打扰文件属性。这样，我可以在 Visual Studio、记事本或任何我喜欢的工具中修改文件。在这方面，版本控制系统应该尽可能透明。有一个 Windows 资源管理器扩展（TFS PowerTools) 允许您在 Windows 资源管理器中处理您的文件，但这并没有极大地简化工作流程。

回答by Sherlock

On top of everything that's been said (

最重要的是已经说过的一切（

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

), 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.

)，这是正确的，TFS 不仅仅是一个 VCS。TFS 提供的一项主要功能是本机集成的错误跟踪功能。变更集与问题相关联并且可以被跟踪。支持各种签入策略，以及与 Windows 域的集成，这是运行 TFS 的人所拥有的。与 Visual Studio 紧密集成的 GUI 是另一个卖点，它吸引了低于平均水平的鼠标和点击开发人员及其经理。

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.

因此，将 Git 与 TFS 进行比较并不是一个合适的问题。正确但不切实际的问题是将 Git 与 TFS 的 VCS 功能进行比较。那时，Git 将 TFS 吹出水面。但是，任何认真的团队都需要其他工具，而这正是 TFS 提供一站式目的地的地方。

回答by bytedev

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.

如果您的团队使用 TFS 并且您想使用 Git，您可能需要考虑“git to tfs”桥。本质上，您每天在计算机上使用 Git 工作，然后当您想要推送更改时，将它们推送到 TFS 服务器。

There are a couple out there (on github). I used one at my last place (along with another developer) with some success. See:

那里有一对夫妇（在 github 上）。我在最后一个地方（与另一位开发人员一起）使用了一个并取得了一些成功。看：

https://github.com/spraints/git-tfs

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

https://github.com/git-tfs/git-tfs

回答by Pieter Gheysens

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.

经过一番利弊之间的调查，我参与的公司也决定选择TFS。不是因为 GIT 不是一个好的版本控制系统，而是因为 TFS 提供的完全集成的 ALM 解决方案最重要。如果只有版本控制功能很重要，那么选择可能是 GIT。然而，对于普通开发人员来说，陡峭的 GIT 学习曲线可能不会被低估。

See a detailed explanation in my blog post TFS as a true cross-technology platform.

请参阅我的博客文章TFS 作为真正的跨技术平台中的详细解释。

回答by jessehouwing

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).

Git 的整个分布式事物真的非常棒。它提供了一些 Shelvesets 没有的功能（在当前产品中），例如本地回滚和提交选项（例如Eclipse 的 localhistory 功能）。您可以使用开发人员分支来缓解这种情况，但老实说，许多开发人员不喜欢分支和合并一点。我被要求多次打开 TFS 中的旧式“独家结账”功能（并且每次都被拒绝）。

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 TFSof you wanted it)...

我认为许多大型企业都非常害怕让开发人员将整个历史带到本地工作区并随身携带（例如给新雇主）......窃取快照是不好的，但带走整个历史就更麻烦了。（并不是说您无法从 TFS 中获得您想要的完整历史记录）...

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.

我最喜欢 Git 的地方是 Push/Pull 选项，您可以轻松地向项目贡献代码，而无需提交权限。我想您可以在 TFS 中使用非常有限的用户和搁置集来模仿这一点，但它不如 Git 选项强大。跨团队项目分支也可能有效，但从管理的角度来看，这对许多组织来说并不真正可行，因为添加团队项目会增加很多管理开销。

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 11 附带 TFS Basic，期待分布式 TFS 可能不远了，它允许您将本地 TFS basic 同步到 TFS 12+ 时代的中央 TFS。我会在用户声音中投下我的票！

回答by Paddy

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...

对我来说，主要区别在于 TFS 将添加到您的解决方案 (.vssscc) 以“支持”TFS 的所有辅助文件——我们最近遇到了这些文件最终映射到错误分支的问题，这导致了一些有趣的调试...