dan*_*ann 11 git mercurial branch git-branch
请注意:我不是要重新启动Mercurial或Git更好的论点,我只是有一个技术问题,我作为Mercurial用户,不明白.我也不确定SO是否是提出这样一个问题的正确位置,但它与编程相关.
关于两个版本控制系统Git和Mercurial如何从用户的角度来看彼此不同(例如Mercurial和Git之间有什么区别？和http://felipec.wordpress.com/2011/01)/16/mercurial-vs-git-its-all-in-the-branches /),主要区别在于分支机构的处理.我已经阅读了很多这些讨论,但我一直在问自己这个问题:
为什么Git不将分支名称存储为提交的一部分？
我真的没有理由不这样做; 这意味着数据不能简单地消失,因为没有参考(标记,分支,等等).
我认为在提交中存储分支是Mercurial的一大优点,因为这会使丢失数据变得更加困难.
Git人群的主要观点是支持Git的分支模型,你可以简单地删除分支,并不会阻止Git在每次提交时存储分支的名称:如果删除了分支的提交,那么对该分支的引用.它也不会干扰"廉价分支"的论点:分支管理起来不会更昂贵.我不认为所需的额外存储应该是值得关注的:每次提交只需几个字节.
Von*_*onC 14
关于Git和Mercurial分支的权威来源之一是SO问题:
在Git中,引用(分支,远程跟踪分支和标记)驻留在提交的DAG之外.
(这允许管理有关分支的不同命名空间,用于本地和远程分支)
Mercurial与书签分支(可以推/拉)有类似的概念.
请注意,在Git中,数据不会"消失",因为没有引用:您仍然有reflog来检索那些未引用的提交.
为什么Git不将分支名称存储为提交的一部分？
我真的没有理由不这样做
我们的想法是分开什么从已经改变(在提交)为什么米即从改变(分支的名称)的情况下.
由于您可以快进合并分支,因此一个分支的提交可以随时成为另一个分支的一部分.
这就是为什么JakubNarębski质疑Mercurial"命名分支"的设计(分支名称嵌入在变更集元数据中),特别是对于全局命名空间,不太适合分布式版本控制系统.
您创建了一个分支来隔离开发工作(请参阅" 何时应该分支？ "),但是对于DVCS,应该在任何分支名称下发布该开发工作(提交集).您发布到另一个Git仓库后,您定义的本地上下文(分支名称)可能无效.
Mercurial的基本操作模型非常简单,匿名分支形成有向无环图(DAG),因此这些分支名称并不重要,您将更少地处理它们.命名分支主要用于组织目的(发布分支等),为此我认为全局命名空间更有意义,或者至少不那么令人反感.
Git有一个比Mercurial更复杂和管理的分支模型,即使你的本地更改被视为一个单独的命名分支,并且面对如此多的命名分支,你必须引入命名空间来管理它们.出于同样的原因,Git具有快进合并的概念,这不适用于Mercurial,因为您不会首先创建单独的分支.
这两个概念都增加了额外的复杂性,同时阻止了有用的功能,比如存储分支名称和提交.这是因为你不能存储没有一些全局空间的命名空间分支,而git没有.
VonC在上面引用的命名空间参数中的缺陷是,如果你和我都创建了一个名为"x"的分支,它就会假定存在问题.没有,就像创建命名分支时没有问题,合并它,然后创建另一个具有相同名称的分支.精心挑选的名称描述了分支的作用,无论作者是谁,如果您需要区分更多,作者与分支名称一起存储,并且所有这些都是永久性的.
我认为Mercurial项目是一个非常好的决定,可以将分支名称与提交一起存储.就像提交消息和作者一样,工作的上下文(分支)是重要且有用的元信息.这使得在检查历史记录时更容易看到变更集的流程,因为您可以看到它们所构成的上下文.在Git中我经历过,如果没有这些信息,历史很快就会变成一堆乱七八糟的线条很难制作的头部或尾部.我认为有这个非常值得权衡没有命名空间.
我想你可以说哲学上的区别在于Mercurial将命名分支视为永久元数据,它提供了一系列提交的额外信息,而Git分支是DAG之上的开发人员的非版本管理系统.顺便说一句,Mercurial还以"书签"的名称(从版本1.8开始是核心功能),但它们实际上更像是一种跟踪工具,并且被视为标签而不是分支.
| 归档时间： |
|
| 查看次数： |
1115 次 |
| 最近记录： |