Aus*_*yde 26 version-control mercurial
前几天我刚刚转向版本控制,经过Subversion的糟糕体验后,我转向Mercurial,到目前为止我很满意.
虽然我理解并欣赏版本控制的想法,但我对它没有任何实际经验.
现在,我正在使用它来处理我正在研究的几个网站,并且想到了几个问题:
版本控制新手的任何其他建议？
到目前为止,每个人都给了我很好的建议,但非常注重团队.我想澄清一下:
目前,我只是在我做的一些网站上使用VC.不完全自由职业的工作,但出于VC的目的,我是唯一一个真正触及网站代码的人.
此外,由于我在网站上使用PHP,因此无法进行编译.
这会显着改变您的答案吗？
Spo*_*ike 25
您询问的大多数问题主要取决于您与谁合作.如果你是一个单独的开发者,它应该不重要,因为你可以做任何你想做的事情.但如果你是一个需要共享代码的团队,那么你应该与你的团队成员讨论行为准则应该是什么,因为彼此之间共享变更有时会变得棘手.
关于行为准则的讨论不需要冗长,可以非常简短; 只要每个人都在同一页面上,就如何使用团队中程序员之间共享的存储库.如果您想使用Mercurial中的更高级功能,例如挑选樱桃或补丁队列,那么请尝试使用它们,这样它就不会以负面方式影响您的团队成员,例如在公共存储库上进行变基.
请记住,版本控制必须易于团队中的每个人使用,否则将无法使用.
我应该多久/多久一次？经过任何重大改变后,是否有效？我什么时候做完了？只有当它到达下一个稳定的迭代时？任何错误修正后？
在与团队合作时,有几种方法,但常见的规则是尽早提交.您应该经常提交的主要原因是使合并冲突更容易处理.
只要合并了由至少两个人更改的文件,因为他们一直在同一行上进行编辑,就会简单地放置合并冲突.如果您持续进行涉及跨多个文件的多行更改的非常大的更改的提交,则管理接收器以管理可能发生的冲突将变得非常困难.如果上述一组更改持续太长时间,则合并冲突变得更加难以处理.
经常提交的规则有一些例外,一个是每当你有一个突破性的变化.虽然如果你有能力在本地提交(你在Mercurial和git本身就是这样做的),你可以提交重大修改.只要您修复了任何损坏的内容,就应该在修复自己的重大更改时将其上游到共享存储库.
当我想要改变菜单的布局,然后合并回来时,我会分支吗？我应该分支吗？
有许多分支策略可供选择(有1998年的Streamed Lines论文,有一个详尽的分支策略列表),当你自己制作它们时,它应该是自己开放的游戏.但是,当团队合作时,如果您需要分支,最好与团队公开讨论.每当你有分支的冲动,你应该问自己以下问题:
我未来的改变会破坏他人的工作吗？
在我完成之前,我的团队是否会对我将要做的更改产生直接的负面影响？
我的代码一次性代码吗？
如果答案是肯定的上述任何你的问题应该大概分支公开,或保持它自己(因为你可以在几个方面做,在水银).您应首先与您的团队讨论如何执行整个程序,看看是否有其他方法可以执行此操作,如果您要重新合并您的更改,有时候有些因素在起作用,而不需要分支(这主要与代码的模块化程度有关).
当您决定分支准备处理合并冲突时.假设创建分支并使提交能够将其合并回"主分支"的人是明智的.在这些时候,如果团队中的每个人都做出相关的提交评论,那就太棒了.
作为旁注:你确实写好了提交评论,对吗？对!？一个好的提交注释通常会告诉我为什么进行了特定的更改或者提交者正在使用什么功能而不是一个不起眼的"我做了提交"的评论.这使得处理大合并冲突的人更容易找出可以覆盖哪些行更改以及在修订历史记录中要保留哪些行更改.
编译时间或构建时间,有时会参与您可能的分支讨论.如果您的项目构建时间较慢,那么在分支机构中使用分段策略可能是个好主意.该策略考虑到所有开发人员应该集成到"主线",并且批准的更改被提升(或"提升")到下一阶段,例如测试或发布线.它通常用开源软件的标签名称来说明,如下所示:
main -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-> ...
\ \ \
test o-----------o--------------o---------> ...
1.0 RC1 \ 1.0 RC2 2.0 RC1
release o----------------------> ...
1.0
与此相关的一点是,测试人员可以在不被程序员打断的情况下工作,并且对于那些处于发布管理中的人来说,已知基线.在分布式版本控制中,不同的行可以是克隆的存储库,它可能看起来有点不同,因为存储库共享版本控制图.然而,原则是相同的.
关于Web开发,几乎没有构建时间.但是,如果要检查难以跟踪的错误,则分阶段(或通过标记发布版本)进行分支会变得更容易回滚.
但是,还有另外一件事情发挥作用,那就是部署网站所需的时间.根据我的经验,版本控制工具在资产管理方面非常糟糕.处理总计高达几GB的艺术资产通常是Subversion处理的一个巨大的痛苦(在Mercurial中更是如此).资产可能要求您以较少的时间处理它们,例如将它们放在以传统方式同步和备份的共享空间中(艺术资产通常不像源代码文件那样同时处理).
在分支,然后合并回来,克隆存储库并将其拉回来之间有什么区别(对于我,一个单独的开发人员)？
与集中式版本控制工具相比,现在分支和保留远程存储库的概念更加接近.你几乎可以认为它们是同一个东西.在Mercurial(和git)中,您可以通过以下方式"分支":
克隆存储库
创建命名分支
创建命名分支意味着您要在正在创建它的存储库的版本控制图中创建一个新路径.创建克隆存储库意味着您将源存储库复制到新位置,并在克隆存储库的版本控制图中创建新路径.它们是分支的两种不同实现,作为版本控制中的一般概念.
在实践中,您应该关注的两种方法之间的唯一区别在于使用.您可以克隆存储库以获取源代码的副本,并且可以存储您自己的更改,并且只要您想为自己进行小型实验,就可以创建命名分支.
由于浏览分支对于那些习惯于直接提交的人来说有点古怪,因此高级用户知道如何操纵他们的版本,因此版本历史是"干净的",例如樱桃挑选或变形.目前,git docs实际上很好地解释了rebase.
这些是我遵循的做法
每个提交都应该有意义:一个错误修复(或一组相互关联的错误),一个(小)新功能等.这个想法是,如果你需要回滚,你的回滚落在定义明确的"边界"上
每个提交都应该有一个很好的消息来解释你提交的内容.真的养成这个习惯,你以后会感谢自己.不必冗长,一些句子可以做.如果您使用的是错误跟踪系统,则将错误号与您的提交相关联也非常有用
既然我使用git和分支是如此快速和便宜,我倾向于为我即将实现的每个新功能创建一个新的分支.我甚至从未考虑过为许多其他VCS做这件事.因此,分支取决于您使用的系统,您的代码库,您的团队等,那里没有硬性规则.
我更喜欢总是使用命令行直接了解我的VCS命令.基于GUI的前端可能导致的断开连接可能是一种痛苦,甚至是破坏性的.控制源代码非常重要,值得深入了解并直接进行.但这只是我的偏好.
备份您的VCS.我使用Time Machine备份我的本地存储库,然后我推送到服务器上的远程存储库,并且该服务器也被备份.VCS本身并不是一个"备份",它可以像其他任何东西一样下降.