使用它后,你有什么优点和缺点?

Kie*_*eli 41 git version-control

我现在正在使用SVN,过去我曾使用过CVS和VSS.SVN是我书中最喜欢的,但我听说过很多关于git的内容.使用git的人中,你的经历有哪些优点和缺点?

Jon*_*eet 29

我对git 没有很多经验,但是:

优点:

  • 它真的很快
  • 本地提交摇滚
  • 快速启动新存储库(无配置等)
  • github很容易使用

(除了能够拥有本地存储库并推送到公共存储库之外,我还没有真正"需要"事物的分布式方面.)

缺点:

  • Windows支持仍然落后,我相信 - 你不能只是从正常的命令提示符中使用它
  • 缺乏IDE和Explorer集成
  • 我花了一段时间才找到一本关于红豆书的好的介绍性文字.
  • "添加"已更改文件的事实只会在该时间点添加内容(因此它可以显示为提交阶段并且仍然需要另一个进行修改git add)需要一段时间才能掌握

  • 真的,从Windows命令提示符使用Git没问题.我一直在使用来自Powershell和cmd.exe的msys Git,暂时没有问题.至于缺乏Explorer集成,那对我来说是一个Pro :-))). (3认同)
  • 噢......我没有意识到git可以从正常的cmd.exe中恢复正常.一定要试试...... (2认同)
  • 如果你喜欢Explorer集成,TortiseGIT似乎工作得很好. (2认同)

小智 19

命令数量

虽然svn和其他现代VCS(如hg或其他)是很好且有用的工具,但git是一个装满机床的商店.这同时兼顾了pro和con.虽然svn有30个命令(根据'svn help'),git会发布130个手册页,每个手册页或多或少都描述一个命令.其中一个原因是git暴露了大多数用户作为命令行工具所需的低级功能.但是,即使没有那些低级命令,git也会提供许多非常强大的工具,并且在我所知道的任何其他VCS中都找不到(参见git-bisect,git-filter-branch,git-cherrygit-reset)举些例子).虽然掌握这些工具非常有帮助,但是初学者很难理解他们需要知道哪些命令,哪些命令不需要知道.


发展模式

类似的话题是git足以支持非常不同的操作模式.这使得初学者很难,因为没有真正的"最佳实践"文档,因为最佳实践不是构建到git中.所以你必须自己决定你是否

  • 只需使用合并以避免与您工作目录冲突
  • 使用重定向到上游HEAD的私有分支
  • 使用上游分支
    • 定期合并(飞鱼)
    • 完成后合并
  • 使用一个项目维护者,树维护者,子系统维护者,驱动程序维护者和贡献者的树,每个级别从下面的级别拉动补丁(linux内核)

由于您拥有本地存储库,您甚至可以使用与您正在处理的项目完全不同的操作模式,并在推送/发布它们之前调整更改集.


变化的路径

根据您的观点,另一个也算作pro和con的事情是使用git比使用任何集中式VCS更复杂,甚至更复杂的大多数其他分布式VCS.

使用集中式VCS,您通常只需执行提交,并且您所做的更改将转到存储库.在git中,更改可以在最终到达最终目标之前经过大量步骤.典型的步骤是(括号中不常见的步骤):

  • 工作目录(编辑)
  • 索引也称为临时区域(git add)
  • 本地存储库(git commit)
  • (其他本地分支)(git rebase,git cherry-pick,git merge)
  • (子维护者的存储库)(git push,git pull,mail)
  • 上游存储库(git push,git pull,mail)

您可以跳过索引,至少涉及2个步骤,但通常还有更多步骤.这需要更深入地了解您正在做什么并输入更多命令.另一方面,这使您可以控制每个步骤.您可以

  • 决定哪些junks/lines进入提交,哪些不进行提交
  • 决定您在哪个本地分支机构中需要哪些补丁
  • 决定发布哪些补丁
  • 在发布补丁之前,返工,压缩,修复,拆分,重新排序补丁
  • 决定自己信任哪些人并接受补丁
  • 将项目的一部分委托给您信任的其他维护者.

所有这些能力和决定使初学者难以开始使用git.一旦掌握,他们就可以对代码进行巨大的控制.


写入权限

任何分布式VCS的一个主要专业人员是贡献者不需要写访问权来从VCS中受益.每个具有读访问权限的人都可以克隆存储库,在必要时创建分支并开始堆叠放置补丁集.在没有写访问权限的情况下使用cvs真的很痛苦 - 使用git,如何获得补丁并没有太大的不同.这不仅是技术优势,而且还可以节省复杂的讨论,无论这个noobie是否应该真正获得写访问权限.


Bin*_*V A 11

优点:

  • 快 - 非常快.
  • 与SVN相比,创建新的repo非常容易
  • 完整的repo只包含在一个.git文件夹中 - 它不会在你的代码的每个文件夹中添加一个.SVN文件夹(不是很大,但我喜欢它)
  • 分支更容易
  • GitHub的!

缺点:

  • 无法检出存储库的一部分(例如只有一个文件夹或只有一个文件)
  • 不跟踪空文件夹
  • 糟糕的Windows支持(不打扰我 - 我使用Linux)
  • 我还没有为Git找到一个好的GUI工具(我使用KDESVN进行SVN).如果您对CLI感到满意,这不是一个大问题.


Bom*_*mbe 10

很多人会否认这一点,但源代码管理工具的选择会影响你的工作方式.我过去常常使用Subversion工作 - 直到我为我发现了Git.我主要避免在Subversion中进行分支.每当我无法避免它时,我更喜欢设置一个本地镜像(使用svk).虽然在Subversion和Git中都可以轻松完成分支,但只有Git才能使合并(和变形!)变得有趣,Subversion在合并时间方面一直是一个巨大的痛苦.

我非常喜欢Git的第二件事(除了已经提到的所有要点之外)是"索引",一个保存下一次提交的暂存区域,以及只能将更改文件的单个块添加到其中的可能性.


Rad*_*Rad 9

Windows的支持令人震惊所以我转向Mercurial,这是另一个同样好的DVCS.

例如,当您在办公室的服务器中拥有一个存储库并且您正在网站上工作时,DVCS的好处就会变得明显.能够在本地提交而无需访问您的服务器办公室(并在必要时进行此回滚)非常棒!


小智 5

使用git与使用其他版本控制系统非常不同.

拥有本地存储库非常重要.这意味着您可以使用版本控制系统的全部功能(这对git来说很多)而不会打扰任何人.如果您的项目中存在争议性问题,您可以私下处理它 - 通过创建分支,堆叠补丁和抛光它们.这样你就可以带着熨平的补丁套装回来.但即使在"正常操作"中,如果你可以在向公众展示补丁之前清理你的补丁要好得多,事实上,如果你有健全的补丁而不仅仅是"一天结束"快照,调试会更容易.

在我提交更大的补丁之前,我通常会对补丁进行重新排序,并将我的新代码上的错误修正直接导入补丁.所以补丁看起来像我从未犯过任何错误.之后,我的私人分支在HEAD之上重新定位然后被推送.我通常从不使用合并,因为它只会使历史变得混乱.

简而言之:它可以保持您的历史清洁.

这使您对工作有了截然不同的看法.它允许您将当前状态视为添加单个修补程序,这些修补程序创建的历史记录不仅仅是日志,而是您有意添加的内容.补丁集是您构建应用程序的砖块 - 并在必要时移动到正确的位置.

我永远不会自愿回到我在git或任何不支持rebase和本地分支和提交的版本控制系统之前使用的任何其他版本控制系统.