关于网站开发的版本控制设置的建议

Question

我们决定开始对我与另外两个人维护/开发的网站使用版本控制。我们目前使用的流程如下：网站托管在专用服务器上。我们的开发工作也在这台服务器上完成，但在现场网站的子文件夹中的网站副本上完成。当一个新功能的实现完成后，我们将更改的文件从这个子文件夹复制到实时网站。正如您可能想象的那样，以这种方式部署新功能相当麻烦，而且同时与多人一起开发也非常困难。

为了改进我们的开发过程，我们决定开始使用版本控制。我对版本控制系统（Subversion和Mercurial）的使用有一些基本的了解，对集中式和分布式版本控制系统的区别也有一些基本的了解。但是，这可能还不足以确定最适合我们要求的设置。

我向我们的托管服务提供商寻求帮助。他们有设置 Subversion 的经验，但没有使用 Mercurial/Git 的经验。所以他们可以为我们设置 Subversion，但是当我们决定开始使用 Mercurial/Git 时，我们必须自己做。但在我们做出这个决定之前，我想就什么是满足我们要求的最佳选择提出一些建议，我将在下面说明。我不介意花一些时间研究如何使用 Mercurial/Git 正确设置解决方案，如果它显然更符合我们的要求，但如果 Subversion 解决方案足以满足我们的要求，我有更好的方式来度过我的时间 :)

我们的主要要求是：

• 轻松将新功能部署到实时网站。

• 即使在将其他功能部署到实时网站之后，也能够还原实时网站中的重大更改（基于用户反馈）。我知道这总会有冲突的可能性，但是哪种解决方案最适合呢？

也许还有其他明显的优点/缺点来选择我错过的两个解决方案之一。

Answer 1

我认为任何版本控制都会极大地帮助你。哪个主题是有争议的（接近宗教！），你会得到每个的优点和缺点的负载。

这是我的看法。我对颠覆很熟悉，对git有点熟悉。虽然 git 是新的、很酷的并且有一些可以说是很棒的特性，但我发现 subversion 在工作环境中的日常使用要容易得多，而且我还没有找到任何人有令人信服的论据来解释为什么拥有存储库的本地版本副本非常重要优于使用颠覆。我确实喜欢使用 github 与开源项目合作，但是由于某种原因，它似乎是一个更自然的环境。

结论？实际上可能没那么重要，选择一个你觉得足够舒服并且你会实际使用它的东西（在我看来，这听起来像是颠覆）。