我向我的开发团队介绍了Git,除了我,每个人都讨厌它.他们想用Team Foundation Server替换它.尽管我对TFS不是很熟悉,但我觉得这是一个倒退的巨大一步.有经验的人可以比较TFS上的分支支持和Git分支吗？另外,总的来说,TFS的优点和缺点是什么？使用Git几年后我会讨厌它吗？
eck*_*kes 259
我想,声明
除了我,每个人都讨厌它
进一步的讨论浪费:当你继续使用Git时,如果出现任何问题,他们会责怪你.
除此之外,对我来说,Git比我最欣赏的集中式VCS有两个优势(Rob Sobers部分描述):
但正如我所说:我认为你正在打一场失败的战斗:当每个人都讨厌Git时,不要使用Git.它可以帮助你更多地了解他们为什么讨厌Git而不是试图说服他们.
如果他们根本不想要它,因为这对他们来说是新的,并且不愿意学到新的东西:你确定你会与那些员工一起成功发展吗？
真的每个人都讨厌Git还是受到一些意见领袖的影响？找到领导者并问他们问题是什么.说服他们,你会说服团队的其他成员.
如果你无法说服领导者:忘记使用Git,那就拿TFS吧.会让你的生活更轻松.
Rob*_*ers 99
两个系统之间的关键区别在于TFS是一个集中式版本控制系统,而Git是一个分布式版本控制系统.
使用TFS,存储库存储在中央服务器上,开发人员签出工作副本,该副本是特定时间点代码的快照.使用Git,开发人员将整个存储库克隆到他们的计算机,包括所有历史记录.
在服务器死机的情况下,在开发人员的计算机上拥有完整存储库的一个好处是冗余.另一个好处是你可以在不修改服务器的情况下在修订版之间来回移动工作副本,这在服务器关闭或无法访问时会很有帮助.
对我来说,真正的好处是,您可以将更改集提交到本地存储库,而无需与服务器通信或对团队造成潜在的不稳定更改(即,破坏构建).
例如,如果我正在开发一个大功能,可能需要一个星期的时间来完全编码和测试它.我不想在周中签入不稳定的代码并打破构建,但是如果我接近本周结束并且我不小心将我的整个工作副本丢了,会发生什么？如果我一直没有承诺,我就有失去工作的风险.这不是有效的版本控制,TFS很容易受此影响.
使用DVCS,我可以不断地提交,而不必担心破坏构建,因为我在本地提交更改.在TFS和其他集中式系统中,没有本地登记的概念.
我甚至没有考虑过在DVCS中有多好的分支和合并,但你可以在SO或谷歌上找到大量的解释.我可以从经验告诉你,TFS中的分支和合并并不好.
如果组织中TFS的论点是它在Windows上比Git更好,我建议在Windows上运行良好的Mercurial - 它与Windows资源管理器(TortoiseHg)和Visual Studio(VisualHg)集成.
Cha*_*ers 86
人们需要放下枪,离开窗台,想一会儿.事实证明,DVCS具有客观,具体和无可否认的优势,这将为团队的生产力带来巨大的变化.
这一切都归结为分支和合并.
在DVCS之前,指导原则是"向上帝祈祷,你不必进入分支和合并.如果你这样做,至少乞求他让它变得非常非常简单."
现在,使用DVCS,分支(和合并)得到了很大的改进,其指导原则是,"做到这一点.它会给你带来很多好处而不会给你带来任何问题."
对于任何团队来说,这都是一个巨大的生产力助推器.
问题是,为了让人们理解我刚刚说过的话并确信它是真的,他们必须首先投入一点学习曲线.他们不需要学习Git或任何其他DVCS本身......他们只需要了解Git如何进行分支和合并.阅读并重新阅读一些文章和博客文章,慢慢来,并通过它直到你看到它.这可能需要2或3整天的大部分时间.
但是一旦你看到了,你甚至不会考虑选择非DVCS.因为DVCS确实有明确,客观,具体的优势,最大的优势在于分支和合并.
Lee*_*som 44
原创:@Rob,TFS有一些所谓的" 货架 ",解决你关于commiting工作正在进行又不影响官方的构建问题.我意识到你看到中央版本控制是一个障碍,但就TFS而言,检查你的代码到架子上可以看作是一个强大的b/c然后中央服务器有一份正常工作的副本在罕见的事件中您的本地机器崩溃或丢失/被盗或您需要快速切换齿轮.我的观点是TFS应该在这方面得到适当的赞扬.此外,TFS2010中的分支和合并已经从以前的版本进行了改进,当您说"......从经验来看,TFS中的分支和合并不好"时,您所指的是什么版本并不清楚.免责声明:我是TFS2010的温和用户.
编辑Dec-5-2011:对OP来说,困扰我TFS的一件事是它坚持在你没有处理它们时将所有本地文件设置为"只读".如果你想进行更改,那么流程就是你必须"检出"文件,这只是清除文件上的readonly属性,以便TFS知道要密切关注它.这是一个不方便的工作流程.我希望它工作的方式是只是自动检测我是否进行了更改,并且根本不担心/烦恼文件属性.这样,我可以在Visual Studio或Notepad中修改文件,或者使用我喜欢的任何工具.在这方面,版本控制系统应尽可能透明.有一个Windows资源管理器扩展(TFS PowerTools)允许您在Windows资源管理器中使用您的文件,但这并不能简化工作流程.
She*_*ock 18
除了所说的一切之外(
),这是正确的,TFS不仅仅是一个VCS.TFS提供的一个主要功能是本机集成的错误跟踪功能.变更集与问题相关联,可以跟踪.支持各种签入策略,以及与Windows域集成,这是运行TFS的人所拥有的.与Visual Studio紧密集成的GUI是另一个卖点,它吸引了不到一般的鼠标和点击开发人员及其经理.
因此,将Git与TFS进行比较并不是一个值得提出的问题.正确但不切实际的问题是将Git与TFS的VCS功能进行比较.那时,Git将TFS从水中吹走.但是,任何认真的团队都需要其他工具,这就是TFS提供一站式目的地的地方.
byt*_*dev 17
如果您的团队使用TFS并且您想使用Git,您可能需要考虑使用"git to tfs"桥接器.基本上,您每天都在计算机上使用Git工作,然后当您想要推送更改时,将它们推送到TFS服务器.
那里有几个(在github上).我在最后一个地方(和另一个开发者一起)使用了一个并取得了一些成功.看到:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
小智 15
在经过一番调查之后,我参与的公司也决定去TFS.不是因为GIT不是一个好的版本控制系统,而是最重要的是TFS提供的完全集成的ALM解决方案.如果只有版本控制功能很重要,那么选择可能就是GIT.然而,对于常规开发人员来说,陡峭的GIT学习曲线可能不会被低估.
在我的博客文章中看到TFS作为真正的跨技术平台的详细解释.
jes*_*ing 14
整个Git的分布式东西真的很棒.它提供了一些功能搁置集没有(在当前产品),如本地回滚和提交选项(如Eclipse的localhistory功能).您可以使用开发人员分支来缓解这种情况,但说实话,许多开发人员不喜欢分支和合并一点.我一直在问到TFS几次过于频繁打开旧风格"的独家结账"功能(并否认每一次).
我认为许多大型企业都非常害怕允许开发人员将整个历史记录带入本地工作区并与之一起(例如新员工)......窃取快照很糟糕,但却带走了整个历史更加麻烦.(并不是说你无法从TFS获得完整的历史记录)...
它提到它是一种很好的备份方式,这对于开源来说非常有用,原来的维护者可能会停下来关心并删除他的版本,但是对于企业计划来说,这对许多企业而言都是不足的,因为没有明确的责任分配保持备份.如果主要的"项目"以某种方式消失,那么很难确定使用哪个版本.哪个会倾向于指定一个存储库作为前导/中心.
我最喜欢Git的是Push/Pull选项,您可以轻松地为项目贡献代码,而无需拥有提交权限.我猜你可以在TFS中使用非常有限的用户和搁置集来模仿这个,但它没有Git选项那么强大.跨团队项目的分支也可能有效,但从管理角度来看,对于许多组织来说这并不可行,因为添加团队项目会增加大量的管理开销.
我还想添加非源控件区域中提到的内容.工作项跟踪,报告和构建自动化(包括实验室管理)等功能从中央领先的存储库中受益匪浅.当您使用纯分布式模型时,这些变得更加困难,除非您将其中一个节点引导(因此返回到分布较少的模型).
随着TFS 11附带TFS 11,期望分布式TFS可能并不遥远,它允许您将本地TFS基本同步到TFS 12+时代的中央TFS.我会在uservoice中对此进行投票!
对我来说,主要的区别是TFS将添加到您的解决方案(.vssscc)以"支持"TFS的所有辅助文件 - 我们最近有这些文件的问题最终映射到错误的分支,这导致一些有趣的调试...
| 归档时间： |
|
| 查看次数： |
154380 次 |
| 最近记录： |