我想知道我是否真的有任何使用git/mercurial的情况.
我工作的项目是java和c#项目,通常有5-20人为共同目标("发布")而努力.大部分的开发商是专业的开发谁重构代码,所有的时间.因此,典型的Linux内核在单独的文件中有大量相对独立的更改,我们有不断变化的重构 - 通常会遇到大量文件和大量代码.没有人害怕在这里改变代码.
现在有了颠覆,我们通过非常接近SVN HEAD来解决这个问题.我们中的一些人甚至在构建服务器的jabber广播上触发了自动svn up.我们大多数人也学会了(或者很快学会)如何规划我们的工作以保持与SVN HEAD的接近.如果你正在进行一次重大的重构,我们会逐步将源树弯曲到新的方向,而不是消失太久.有时您只是计划重构操作并在较少竞争的区域开始.经过这么多年的工作,它成为第二天性.我们大多数人从不离开距离svn头不到2小时的"舒适区".自动构建和svn头是项目"脉冲",我们喜欢它.
当然,我们分支每个版本,但从发布分支回到主干的后退数量迅速减少到足以使其无关紧要(我们已经获得了不错的测试覆盖率).与源的私人分支一起运行数天/周听起来像我们积极想要阻止的事情,并且它不会经常发生.
git和mercurial声音都很酷,git略微更多,因为我更像是McGyver类型而不是James Bond类型.但是当谈到建立实际转换的案例时,感觉就像Linus和我生活在两个不同的星球上.大多数时候,我们希望我们的团队专注于HEAD.
GIT如何让我的版本控制更好？GIT如何让我改进我的流程？我是颠覆恐龙吗？
在心态方面,有时可以创建软分支,执行软分支中的所有更改,测试软分支中的更改结果,然后软分支"完成" ",在本地重新集成主分支,重新测试,然后传播它.
这在某些情况下比冲头更好,因为你没有持续中断其他调试代码的存在,污染你的代码以添加非错误来处理.
它还意味着您可以更频繁地提交,提供更全面的历史记录,因为提交不会立即出现在任何地方造成问题.
此外,在协调软分支与共享主线时,您可以看到一个完整的变更集,向您显示所有集体更改以及所有集体更改,这为良好的代码审查机会打开了大门.
另外,从测试的角度来看,如果你有更多的软分支,你可以在软分支上运行测试,然后再将它们合并回主分支,并且有一个标准,分支不会合并回主分支.分支直到它有
通过自己的测试
在主要分支更改已协调到软分支之后通过测试
因此,为您提供额外的代码质量保证,因为您的主协作分支是额外的干净,因为不允许在其上显示失败的代码.
(这也限制了问题解决领域,因为你只需要测试你自己的变化大部分,当你'完成'时,你只需要担心其他人做了什么,以及他们做了什么也应该通过测试,这意味着当事情没有失败,你只需要看看你做来解决这个问题)
但是我会不断地从中央回购头部更新到我的软分支？这真的是我问题的本质
分支系统的美妙之处在于,您可以根据需要将"被他人认为稳定的任何东西"拉入您的本地副本.
"持续更新"变得不必要了,因为您没有显示相同的问题.
a b center
|
|
/ Key: / - | \ = Flow
/----<---| < > = Flow Directions
| /--<--/ * = Commit
* | | T = Test
| * | M = Merging with "Current" state of common branch
* | | C = Tests Complete and Current state is "sane"
| * |
T | |
| T |
| C |
| |/-<--/
* M |
| T |
* C |
| \--->-\
* /---<-/
T | |
C * |
|/-----<-/
M | |
T * |
| T |
* C |
| |/-<--/
* M |
T T |
C \-->--\
|/---<---/
M |
T |
C |
\---->---\
|
此外,由于系统如何工作,稍后,这也可能发生:
a b center
| | |
T | |
C * |
|/-----\
|
在这种情况下,他们作为"头"的整个概念消失了.它有几十个头,你看到的一个很容易透视.
我还可以补充一点,这些逻辑分支虽然在这里显示为单独的,但可以非常切实地表示单独的结账位置,或者仅仅是单个机器上的不同软分支.a&b实际上可能是一个单一的开发人员.
实质上,"从mainbranch不断更新我的软分支"在概念上毫无意义.因为实际上,还会有主要分支中没有代表的变化,你什么时候才能知道它们是否已被推动？SVN给你这种"奇异"代码状态的错觉,当实际上,当用户在文本编辑器中打开文件时,他们实际上创建了一个非常短暂的生命软分支,即正在发生的变化,没有人知道,并且为了让这种幻觉能够以你认为有效的方式持续下去,实际上,用户必须在每个角色之后做出承诺,这是不切实际的.所以实际上,人们已经习惯了不同位置彼此"不同步"的事实,并学会解决它的方法,因此它不再是问题.
此外,"不断更新我的树与每个人的变化"有一个核心问题,因为,你有太多的分心,你不断被别人正在做的一切轰炸,如果他们正在制作一系列1 line承诺测试他们无法在自己的机器上测试的东西,然后你对不断变化的文件进行噩梦,看到随机变化的用户无法理解它们.
通过在提交之间允许更长的运行,然后批量查看净结果并且只看到同行的最终结果一次性更改,您可以立即看到自签出后已更改的代码以及它的含义的内容概述对于你的代码,你可以编写自己的代码并完成它.
从简单的事情开始,不要过渡冷火鸡,DSCM中的一些概念可能有点令人生畏(我看到很多人都难以理解垂直堆叠软枝的概念),移动一个小的非Git/Mercurial代码库的重要组成部分,并与它一起玩了一段时间,试验它的好处和它可以做些什么.没有比自己体验更好的证据了,我所有可爱的解释都不太可能传达你需要理解的内容,只能通过尝试来学习,并且失败几次(因为失败是学习的关键部分)
您的团队使用Subversion的方式意味着发生了相当多的合并工作.几乎每次团队成员更新到最新的主线时,他们都会将他们的工作副本与最新的主线合并,即使他们在此阶段没有提交自己的更改.合并开销倾向于成为提交率和团队成员数量的产物,并且由于提交率是团队成员数量的函数,因此源代码管理开销为O(N ^ 2).
在Mercurial/Git模型中,这种合并工作将在团队中共享.如果您经常从每个人那里获取变更集,那么通常您会发现其他人已经完成了您可能必须完成的几乎所有合并工作.而且,在合并破坏的情况下,人们通常已经修复了它.协调一对分支只需要进行一次,并且由于生成新分支的速率与团队成员的数量成比例,因此源代码管理开销是O(N).
我希望20个在一个分支上工作的开发人员可能会涉及相当多的合并工作(处理冲突,并处理由于独立开发导致的回归),所以如果你尝试Mercurial /我会感到惊讶Git并没有找到有用的生产力胜利.您认为您可以根据当前的进度管理100名开发人员吗？我估计Linux内核开发人员的数量是4000,但他们完成了很多工作,总源代码管理开销必须是可以接受的.
只要您的源代码管理系统跟踪共同的父母,合并通常是自动的.由于更改之间的交互,每个合并都有可能是文本冲突或破坏构建和测试; 你必须做的合并越少,你花在处理任何一种问题上的时间就越少.
因此,一个非常大的胜利是Mercurial/Git用户不再害怕分支机构.在BitKeeper(据我所知,真正引入这种工作方式的工具)之前,持久的分支是时间炸弹滴答,偶尔爆炸并需要一个星期才能恢复.现在,我们可以毫不犹豫地分支,相信我们以后能够合并.在一个健康的团队中,其他人可以看到您的分支机构正在进行中,并将它们合并到他们的分支机构中,如果他们认为值得,可以在以后投入您 在一个集中模型中,如果每个开发人员有3个或4个分支处于活动状态,而我正在纠正它说是O(N ^ 2),那么你只是将源代码管理开销增加了3倍^ 2,即一个数量级,这可能足以真正伤害整体健康,财富和幸福.
京公网安备 11010802040832号 | 京ICP备19059560号-6 