前几天，我刚刚转向版本控制，在经历了Subversion的糟糕经历之后，我切换到了Mercurial，到目前为止，它对此感到满意。
尽管我理解并赞赏版本控制的思想，但我实际上没有任何实践经验。
现在，我正在将其用于正在工作的几个网站，并且想到了几个问题:
对于版本控制新手还有其他建议吗？
到目前为止，每个人都给了我很好的建议，但是非常以团队为导向。我想澄清一下:
目前，我只是在旁边的某些网站上使用VC。并不是完全自由的工作，但就VC而言，我是唯一真正涉及网站代码的人。
另外，由于我在网站上使用PHP，因此无需进行编译。
这会大大改变您的答案吗？
最佳答案
您要问的大多数问题主要取决于您与谁一起工作。如果您是一个孤独的开发人员，那么没关系，因为您可以做任何想做的事情。但是，如果您所在的团队必须共享代码，则应与团队成员讨论行为准则应为什么，因为彼此之间共享更改有时会变得棘手。
关于行为准则的讨论不必冗长，可以很简短。只要每个人都在同一页上，就如何使用团队中程序员之间共享的存储库。如果要使用Mercurial中的更高级功能(例如，挑选樱桃或补丁队列)，请尝试使用它们，以免对团队成员产生负面影响，例如重新建立公共(public)存储库。
请记住，版本控制必须易于团队中的每个人使用，否则将无法使用。
与团队合作时，有几种方法，但是通用规则是提早提交，通常是。为什么应该使用commit often的主要原因是使合并冲突更易于处理。
只要合并至少两个人更改过的文件而无法工作，因为他们一直在同一行上进行编辑，则仅发生合并冲突。如果您要进行的提交涉及到非常大的更改，并且跨多个文件进行了几行更改，那么对于接收方来说，要管理可能发生的冲突将变得非常困难。如果上述更改集被保留太长时间，合并冲突将变得更加难以处理。
经常提交的规则有一些异常(exception)，一种是每当您进行重大更改时。尽管如果您有能力在本地进行提交(您本质上是在Mercurial和git中进行的)，则可以提交重大更改。只要修复了任何故障，就应在修复了自己的重大更改后将其向上游推送到共享存储库。
有很多branching strategies供您选择(1998年的Streamed Lines论文中就有exhaustive pattern list of branching strategies)，当您自己制作它们时，它应该是您自己的开放游戏。但是，在团队中工作时，如果需要分支，最好与团队进行公开讨论。每当您有分支欲望时，都应该问自己以下问题:
如果以上任何一个问题的答案都是肯定的，那么您可能应该公开分支，或者自己保留(因为您可以通过Mercurial采取多种方式来做到这一点)。您应该首先与您的团队讨论如何执行整个工作，以查看是否还有其他方法可以完成，如果您打算将所做的更改重新合并，有时会有些因素在起作用，您无需分支(这主要与代码的模块化程度有关)。
当您决定分支时，准备处理合并冲突。假定创建分支并进行提交的人员能够将其合并回“主分支”是理智的。在这些时候，如果团队中的每个人都做出相关的提交评论，那就太好了。
附带说明:您确实撰写了不错的提交评论，对吗？对!？一个好的提交注释通常会告诉为什么做出了特定的更改，或者提交者正在处理什么功能，而不是非描述性的“我进行了提交”类型的注释。这使处理大合并冲突的人更容易确定哪些行更改可以被覆盖以及在修订历史记录中保留哪些行更改。
有时甚至是编译时间或构建时间，也可能会涉及到分支讨论。如果您的项目的构建时间很慢，那么最好在分支机构中使用暂存策略。此策略考虑到所有开发人员都应集成到“主线”，并且将批准的更改提升(或“提升”)到下一个阶段，例如测试或发布线。经典地用开源软件的标签名来说明，如下所示:
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开发，实际上没有构建时间。但是，如果要检查难以跟踪的错误，则分阶段进行分支(或通过标记发行版本)可以使回滚变得更容易。
但是，还有另外一件事起作用，那就是部署站点所花费的时间。根据我的经验，版本控制工具确实对 Assets 管理不利。在Subversion中，处理总计达几个GB的艺术 Assets 通常是一个巨大的难题(在Mercurial中更是如此)。 Assets 可能会要求您以另一种耗时较少的方式来处理 Assets ，例如将其放置在以传统方式进行同步和备份的共享空间中(艺术 Assets 通常不会与源代码文件同时使用)。
与集中式版本控制工具相比，现在分支和保留远程存储库的概念更加接近。您几乎可以认为它们是同一件事。在Mercurial(和git)中，您可以通过以下方式“分支”:
创建命名分支意味着您正在版本控制图中为要在其上创建存储库的路径创建新路径。创建克隆的存储库意味着您要将源存储库复制到新位置，并在克隆的存储库的版本控制图中创建新路径。作为版本控制中的一般概念，它们都是分支的两种不同实现。
实际上，您应该关注的两种方法之间的唯一区别是用法。您可以克隆存储库以获取源代码的副本，并可以在其中存储您自己的更改，并在每次想自己做一些小实验时创建命名分支。
由于对于习惯于直线提交的用户来说，浏览分支有点古怪，因此高级用户知道如何操纵其版本，因此版本历史记录可以“清理”，例如: cherry picking或rebase。目前git docs实际上对rebase的解释相当好。