2011-05-15 148 views
68

在基于Windows的操作系统上使用Git扩展或TortoiseGit有什么好处和缺点?TortoiseGit vs Git扩展

+6

如果你已经习惯了例如TortoiseGit,那么TortoiseGit是一个不错的选择。 TortoiseSVN的。这是一个外壳扩展 - 所以你需要从Windows资源管理器中工作。 GitExtensions是一个完整的Windows应用程序,您可以从Windows资源管理器单独启动;但有时候我感觉有点“奇怪”,并不像我期望的Windows实用程序那样完全工作 - 并且崩溃并冻结了很多(至少对我而言)。 – 2011-05-16 04:57:27

回答

93

我不知道GitExtensions,但我可以分享我的TortoiseGit经验(由marc_s的评论提到):

优点:

  • 与Windows(这是一个外壳扩展)
  • 完美集成
  • 与TortoiseSVN几乎相同的用户界面(如果您已经使用过TortoiseSVN,您知道该期待什么)。

缺点:

  • 你将有一个时间了解如何使用git。

与TortoiseGit的问题是,谁与TortoiseSNV工作过的人都会认为一切将(或应该)工作酷似SVN ......并最终从来没有真正理解如何使用Git工作。作为个人经验,我工作的公司2年后从SVN迁移到git,每个使用TortoiseGit的开发者都不知道自己在做什么,有时甚至搞砸了他们的本地存储库。最后,他们放弃了TortoiseGit,花时间学习git“困难的方式”(shell,Windows上的msysGit),从此以后每个人都很开心。

结论:直接使用msysGit并正确学习git。你将在未来避免许多头痛。

+9

好利弊争论+1 – 2012-11-29 02:48:46

+1

作为另一种方式的人,从使用Git Extensions到另一个项目需要使用TortoiseSVN,我发现使用TortoiseSVN非常刺激。倾向于搞砸了SVN存储库,尽管我最终习惯了它。根据我的经验和拉斐尔的评论,我认为Tortoise的做事方式和git之间肯定存在阻抗不匹配。 – 2013-03-09 13:50:33

+4

我个人使用TortoiseGit进行提交(仅查看提交)和日志查看,对于其他操作使用命令行 – 2013-09-05 14:33:14

25

我的公司尝试并迅速放弃了Tortoise Git。它经常坠毁。编码者声称Tortoise Git不够强大,但我没有自己检查。但我确实看到了很多自己的崩溃。

编码者更喜欢git bash,其他人使用但讨厌git扩展。虽然其中一些人还额外打开了git bash。 Git bash不可避免地要看到进度计数器。

Git扩展没有选项可以显示拉动过程中的进度计数器。所以只有Git Extensions,你坐在一个神秘的非进度栏前面,不知道会发生什么以及是否失败。最糟糕的是缺少或不正确的密码:Git扩展只是让你永远等待,显示同样的辉煌吧,就好像它正在做一些耗时的事情。 Git Extensions的另一个惊悚之处在于,当“版本化”许多大文件并使用rebase进行提取时,会出现“内存不足”的情况。在这种中止之后,非编码用户总是被问题困扰。他们没有更改的许多文件显示为已更改,并且锁定文件阻止他们处理问题等。

在我看来,这两种GUI工具都不成熟。

+7

最后一句话+1。 – mbx 2011-08-08 08:53:12

+0

作为更新,虽然错误信息仍然有点令人困惑,但它们实际上现在已经正确显示。 – 2012-11-16 14:26:07

+6

很久以前,Git Extensions支持在拉取期间显示进度。 Git进程中断也是固定的。 – KindDragon 2013-03-04 18:52:01

0

日期:2011-08-27。

此时,Tortoise Git根本不起作用,并且谷歌代码网站上的问题在一个月内没有得到关注:http://groups.google.com/group/tortoisegit-users/browse_thread/thread/9090337b7936e1e1

从Tortoise Git的第一次使用克隆一个网站(并开始开发)的弹出框中的“加载修补程序密钥”框是灰色的。所以没有找到私钥,并且错误消息是“连接中断”成功!!!!

尽管控制台为基础,但Git Bash完美工作。如果上面的每个人都谈论了在使用Tortoise Git时不了解Git概念,那么即使没有考虑到我花了3个小时来尝试让Tortoise Git为开发人员工作,我也会远离它。他将不得不学习控制台Git,或者走下去。

我得到了它在15分钟内的工作,我只是想聘请程序员;-)

PS黑客,Eclipse有三大版本控制库“连接器”可以是一个非常好的编辑器。

+4

日期:2012-9-4:一年后,问题解决了吗?我说TortoiseGit正在改进 – linquize 2012-09-04 06:30:23

13

我对TortoiseGit没有多少经验,但是我已经安装了,并且正在使用GitExtensions v2.21。

最大的优点在于使用GitExtensions:

  • 视觉gitk般的代码行及分支机构的图形显示,在卡上提供所有必要的信息,从而无需任何与不友好SHA的工作。
  • 以管理员和所有其他用户安装在同一台PC上的能力可以像任何普通用户一样使用它。
  • 内置外壳集成与Windows资源管理器
  • 了与Visual Studio的盒子整合(视窗Eclipse用户只需要msysgit,因为他们有自己的GUI,以取代GitExtensions的需要)
  • 易于使用的安装程序它预先打包了所有必要和先决条件的功能,以开箱即用(SSH Client,KDiff,msysgit)。
  • 整合与GitHub的(叉,克隆,拉都是流线型)

缺点:

  • 文档不会持续不断地添加新的功能跟不上。例如,我仍然不知道如何使用脚本功能。

我们不要忘记,这是一个完全免费的程序,并提供给我们,不附带任何条件的选择,我没有看到这样高的期望放在它的理由,因为如果我们支付客户? 我已经看到了前面的用户提到的一些中止和冻结,但我相信大多数已经在v2.24中得到了修复。很多中止和失败的行为并不是GitExtensions的错,但更多的是GitExtensions之外的系统问题的症状(例如,配置错误的SSH设置,托管远程回购的服务器上的文件权限问题等)。例如,有一次,我做了一次简单的推动,导致失败并中止。事实证明,我尝试推送的远程路由器的路径名非常长,导致承载该repo的Mac服务器出现问题。

不管怎么说,然而,我说GitExtensions的经验是相当积极的。我发现上面列出的好处使得值得忍受偶尔的异常终止并冻结,直到错误得到修复。

18

你想要Git扩展的一个重要原因 - 它显示了提交日志的图形视图(见下文)。如果没有这种图形视图,我认为大多数人都不会知道git会发生什么事情发生在分支机构,提交,重新发布,樱桃采摘等等上(我知道我没有)。

你也想在命令行上做一些你的工作,这是你最好的选择,因为你得到的所有帮助都是基于命令行的。所有这一切,你也可以使用Tortoise Git(假设它有效),因为它们都调用相同的命令行可执行文件,并在同一个git存储库上运行。

大多数IDE都支持git,JetBrains IDEA在添加变更列表和其他功能方面做得非常出色。

Git Extensions log view

+6

这是一个非常重要的考虑因素。由于其CVS/SVN传统,TortoiseGit是面向文件和目录的。但git本身并不是 - 它是以历史为导向的,文件和目录恰好是历史关注的东西。实际上,任何通过文件/目录上下文菜单访问主要访问途径的Git工具都是有缺陷的。这也包括Git扩展。 – Jeremy 2012-12-20 15:45:26

9

只是为了对付上述的一些言论:

有了正确的预期,TortoiseGit提供了极好的图形用户界面的使用Git在Windows上工作。它不是TortoiseSvn的替代品,而是使用gitk + git-gui(可以被认为是核心git功能的一部分并可在msysgit中访问)的改进gui。我看到的唯一不好的事情是你不需要记住所有的checkout/rebase/merge等确切的命令,因为可以通过gui(这是整个点)非常方便地完成所有操作。 putty/ssh问题更多地与Windows上对ssh的低级支持有关,而不是TortoiseGit独有的。

+1

也支持** TortoiseGit **:1)在没有GE等几秒负载延迟的旧PC上,速度要快得多; 2)它允许在默认的diff-viewer中编辑当前文件; 3)它在上下文菜单中有更多的选项; 5)它在提交查看器中具有可配置的列; 5)它介意GUI中的'autocrlf'设置(即,不像GE那样在分级中重新发出警告); – Annarfych 2016-12-11 04:57:23

+0

只用它openssh而不是腻子和快乐 – 2017-01-25 06:20:06

10

我不能说Git扩展,因为我从来没有用过它。纯GIT有一些问题。例如,无法整合GVIM。 Tortoise Git有一个集成的编辑器和diff工具(这非常棒),所以这是一个很好的方便。我喜欢Scott Chacon书中的分支图,并希望TGit会有类似的图。他们确实有一个显示分支的工具,但它不如书中的那么好。

有一点需要记住的是,由于TGit只是GIT之上的一个shell,所以混合这两种方法并没有什么坏处。我使用TGit来处理大多数事情,但是在GIT中使用那些很尴尬的命令,或者我在TGit中很难理解。但即使你打算使用TGit,如上所述,仍然很重要,首先要了解GIT的基本知识。我通读了Chacon一书中的第一章,即三章(可在http://progit.org/book/上免费在线或在亚马逊购买)。如果你和我一样,你可能想多读几遍,让这个范例沉入其中。这并不复杂,但与以前的VCS非常不同。

TGit从来没有撞到我身上,就像其他一些评论者一样,但后来我的回购很少。它确实在不止一次的情况下吃了我的提交意见,这可能是用户错误。由于您可以返回并重新编辑注释,这只是一个烦恼,值得使用GUI的便利性,一眼就能看到大量信息的窗口。

+0

只想评论我有同样的经历。使用TGit除非对较不典型的操作更容易使用bash。 TGit有一个伟大的日志,伟大的内置差异,现在在2016年是坚实的。 – Raj 2016-10-26 01:34:41

5

快速和容易的编辑,定制和大楼的扩建, GitExtensions是更好的(C#)比TortoiseGit(的Visual C++ MFC)

对于便携性, GitExtensions是在Linux上的Windows /单声道更好(.NET /苹果机)比TortoiseGit的(Win32/64只)

要在资源管理器使用图标叠加,使用TortoiseGit

对于某些功能的性能, TortoiseGit是更好,因为它调用静态/动态库检索结果从存储库中,而GitExtensions只调用具有较大开销的git.exe命令行。

要迁移在TortoiseSVN, TortoiseGit会更熟悉的莫过于GitExtensions

+1

您不需要专业版的visual studio来编译GitExtensions,但是您需要TortoiseGit – linquize 2012-09-04 06:27:32

+1

如果您要构建GitExtensions的外壳扩展,则需要专业版。核心部分使用Express Edition进行编译, – linquize 2013-02-20 01:31:08

+0

TortoiseGit调用libgit2,因此它** **速度更快(大写且大胆) – 2017-01-25 06:22:11

7

我用GitExtensions。我还没有使用过TortoiseGit,但我们其他的开发人员都喜欢它,并拒绝使用GitExtensions。他的推理是:1)熟悉; 2)它有很大的Windows资源管理器集成。

使用GitExtensions我倾向于使用只有三样东西在Windows资源管理器集成:

1)要创建新的本地存储库(上下文菜单项的Git初始化这里,这实际上是Windows命令一个Git; GitExtensions坐镇在Git for Windows之上);

2)打开Git Extensions GUI(浏览窗口);

3)将远程存储库克隆到本地存储库(上下文菜单项“Git扩展”>“克隆”)。

对于几乎所有其他事情,我只需要GitExtensions GUI并从那里开始工作。

GitExtensions的开发人员声称几乎所有的命令都可以从GUI执行。这并不完全正确,但我发现我只需要在复杂的任务中每月进入一次或两次命令行界面。

在某些情况下,通过隐藏基础Git命令的复杂性,GUI使得复杂任务变得简单。这有时涉及将几个Git命令组合成一个单独的动作。例如,在GUI中组合添加子模块,初始化子模块并将其更新为单个动作的子模块。在另一种情况下,GUI通过提供Git缺少的命令来简化任务 - 删除子模块(在Git中,您必须手动编辑各种文件,例如.gitmodules和.git/config以删除子模块)。我很想知道TortoiseGit是否以类似的方式简化了复杂的任务。

GitExtensions还具有相当基本的Visual Studio集成。不知道TortoiseGit是否。 Visual Studio 2008和2010中有一个单独的Git源代码控制提供程序,它提供了更广泛的Visual Studio集成。但是,安装了Git源代码管理提供程序后,我发现我从来没有使用它。我从Visual Studio中使用的唯一GitExtensions集成在工具栏上,用适当的存储库打开GitExtensions GUI。我将在一台显示器上使用Visual Studio并在另一台显示器上打开GitExtensions。

至少从版本2.32 GitExtensions显示其工具栏中未提交文件的数量。我以前使用2.24,它没有这个功能,非常方便。对是否存在任何未提交的更改提供即时反馈。