转向源代码控制

我们是一家规模很小的公司（3-4位程序员和3-4位网站设计师），它开发了一个单一用途的PHP Web应用程序，该应用程序可为大约100多个网站提供功能。我们已经在一个单独的开发和生产环境中运行了两年，效果很好。总是有足够多的独立功能要开发，以使程序员们再也不会真正冲突了，并且在没有源代码控制的情况下工作起来更加方便。即使这样做有造成数据丢失的风险，而且我们在无意间采取行动也丢失了相当一部分文件。

另一个考虑因素是我们的设计师不精通技术（我向他们介绍了html标记，而不是使用WYSIWYG）。这是不愿转向版本控制的原因之一。

但是，现在我们已经有100多个站点，并且开发团队正在壮大，我正在尝试对我们的过程进行标准化，并且就程序员而言，源代码控制似乎是合乎逻辑的一步。我希望这也可以加快我们的补丁程序部署。

不幸的是，我在建立源代码控制系统方面的经验非常有限。我很好奇从设置类似的人那里听到的消息，或者有进行切换的经验：

1）是否对所有内容（站点，css，html模板和应用程序代码）进行版本控制，从而迫使设计人员学习版本控制？还是仅开发人员才能处理应用程序代码？

2）最初设置源代码管理时要注意哪些陷阱？

3）部署dev =>用于源代码控制的生产技巧。

感谢您的见解。

编辑1：当当。到目前为止，每个人都建议控制一切。那会让我早点掉头发。在不久的将来，这可能会引发一个新的问题。感谢到目前为止的建议，请继续关注！

编辑2：有很多好的答案，我们将研究各种版本控制系统。感谢大家的答复！

对所有版本进行版本化（即使对于设计师而言）也很有帮助。如果实施得当且受过良好的培训，我认为他们会发现它比麻烦的多有用。

如果您刚刚起步，我强烈建议您使用git或mercurial之类的分布式版本控制系统。这是世界上的普遍趋势，并且有很多优势。它很容易在断开模式下工作，没有网络依赖性，并且能够在版本控制下进行私有的，未打扰的工作，并在准备就绪时集中检查所有内容。

并且，不要诉诸权威或其他任何东西，而要查看Joel Spolsky 在该主题上必须说的话。（选择语录：“ Subversion =Leeches。Mercurial和Git = Antibiotics。”）他提出了有趣的一点，即这些新系统使用了不同于传统版本控制的新思维模型-这就是为什么要采用这种从一开始的方法就是胜利。

我会说将所有内容置于版本控制之下。一旦一切正常，您可以将其复制到一个标签，对于大多数SCM系统，该标签不需要服务器上的大量磁盘空间。

就最初的陷阱而言，您不必担心太多。将所有内容提交给服务器，如果不正确，则可以将其改组并稍后删除多余的内容。我唯一不会提交的是从源构建的工件，即Java代码文件属于版本控制，但不属于“从源构建”二进制文件的已编译类或整个ISO / DVD。

开发到生产很容易，在每个主要里程碑都创建了一个分支。版本控制系统中的目录布局通常类似于：

/ trunk / project / branches / project / version1 / branches / project / version2 / branches / project / version3

假设您在产品的版本2中发现了一个错误，然后导航至该分支，对其进行了修复，然后发布了2.1版。在使用新版本4的/ trunk / project文件夹时，始终由您决定哪些功能可以前后合并。

不要让SCM酷爱喝酒的人弄糊涂，因为流行的版本控制系统在功能上几乎没有什么区别，即Subversion和Git。对于您的团队而言，最重要的事情是这些服务器与您现有工具的集成程度。我也不喜欢所见即所得，但是拥有eclipse-php或与服务器兼容的其他IDE肯定很好。

我是一名开发人员，之前曾参与过IT管理员工作。

要回答您的特定问题：

1）是的，版本化所有内容。

2）建议您建立一个虚拟版本控制存储库和一个虚拟项目供人们学习。

3）标记要投入生产的版本。甚至是审判。然后，您始终可以签出某人正在运行的特定版本。

我看到您已将问题标记为CVS。

我的建议是认真考虑Subversion，并与TortoiseSVN结合使用，这使其非常易于使用。也有一个TortoiseCVS。

我建议您运行有关版本控制的内部教程。如果您的开发人员/设计人员以前从未遇到过，我会感到惊讶。乌龟只是使其非常用户友好。

将其中一个Web界面安装到cvs或subversion中也是有益的。

我建议通过CVS进行颠覆的原因是，尽管CVS非常好，但它存在一些严重的设计和实现问题。对我来说，最大的缺点是：1）您无法对目录进行版本控制2）二进制文件处理不是很好，因为很多事情默认为文本。3）没有原子提交。4）我记得它经常弄乱我必须从代​​码存储中手动删除的锁文件周围。由于您拥有rm锁定文件，因此这样做有损坏的余地。5）SSL支持和管理用户/密码

Subversion基本上解决了所有这些问题，可能还有许多其他问题。它还具有很多高级功能，例如外部功能（我实际上确实使用过）。并且可能将用户/组链接到您可能会发现有用的活动目录中。当时我使用了不可用的CVS。可能是现在，我还没有检查。

使用svn可能最大的不同是您不创建标签。而是在项目目录复制到“标签”文件夹中并为其指定名称的情况下，创建看起来似乎是副本的副本。看看文档，您会明白我的意思。我知道它看起来很奇怪，但是您已经习惯了。

该网站可能会有一些好处（尽管我不能保证）：为php网站http://www.howtoforge.com/set-up-a-modular-svn-repository-for设置模块化svn存储库 -php-网站

高度重视上面显示的许多知识-这是明智的做法-版本控制的推出就像监视系统的推出一样。我的客户说“我应该监视什么”，而显而易见的答案是“监视所有内容”。但这不是可喜的消息：它们拥有350个系统，每个系统具有20-30个系统变量以及一堆特定于使用情况的变量，并且可以对所有这些变量进行有效监控。但只有我一个人，他们希望在两周内看到一些结果。

因此，尽管我同意最佳实践是对所有内容进行版本控制，但是如果这首先不可行，请从控制迄今为止缺乏大多数控制权的事情开始。

如果大多数中断是由应用程序代码引起的，请首先进行控制；如果大多数是通过计划外的CSS补丁来控制，等等。

这不仅可以为您带来最佳的投资回报，而且还为您提供了将来扩展版本控制使用的合理理由：“由于我们在应用程序代码中添加了版本控制，因此30分钟内计划外停机已从每月11个下降到2个。这两个是由静态HTML更改引起的，因此我们打算接下来对它们进行版本控制。”

逐步推出还可以为您提供组织内部的熟练用户。是的，您必须教所有六个应用程序开发人员如何使用该系统，但是他们学到了，他们对此表示满意。现在是时候将系统推广给CSS团队了，您的内部专家比三个月前多了六位。到这个时候您甚至可能已经有了convert依者；能够迅速撤消具有破坏性的变更而节省了资产的开发人员可能是CSS团队的最佳传播者。

编辑1：如果您决定走这条路，那么便宜的芯片支持就是至少在生产盒的顶部增加绊线。这样一来，如果事情打破，但VCS说，这是没有什么它目前拥有的，你可以快速识别哪些责任已经 改变，这既加快了修复，并提出您的下一个候选版本控制。

版本控制一切。将HTML文件置于版本控制之下，然后由于CSS的变化无法控制而使站点完全被破坏是没有意义的，因此无法轻易撤消。

陷阱：在我公认相当有限的版本控制使用期间，我个人没有遇到任何问题。

部署：目前，无论是在办公室还是在家里，我都使用Windows主机上托管的Subversion。Windows仅因为这是可用的。否则，它很可能是另一个操作系统。非技术用户的关键在于给他们一个简单的基于GUI的工具来处理导入，导出，提交，差异等。要使用哪种工具在一定程度上取决于所使用的OS和VCS系统。

使用：当我进行代码更改时，我经常测试并提交。这使我可以在拧紧螺丝时尽可能地返回。另外，通过比较各种修订版本和复制部分代码，我不必失去所有更改，仅因为我需要恢复到以前的版本才能在代码的另一部分中修复某些内容。

额外的好处：您可以通过VPN或安全连接访问源存储库，从而允许用户在家中或其他地方工作。例如，我可能在家里有了一个主意，然后在那儿编辑我的工作代码，然后才失去主意。

版本一切。

部署取决于您必须为每个这些站点“自定义”多少。如果除了一个或两个配置文件外，它们是相同的，则只需签出代码的副本，然后进行较小的更改。根据需要，为每个客户端运行版本控制的update命令。

如果采用“直接在客户站点中签出”分发模型，则需要确保服务器排除对版本控制目录的访问，以使人们无法浏览到http://example.com/。 git /并查看您的内部结构。另外，我肯定会为每个客户端提供一个测试和生产虚拟主机，以确保站点更新不会麻烦。特别是如果您要对各个客户的文件进行自定义更改，则需要先处理冲突，然后才能进行更改。在这种情况下，您将签出/更新测试虚拟主机，并且在一切正常时，将测试虚拟主机复制到生产虚拟主机。

人们所说的关于版本的东西都是好的。

如果您决定进行颠覆，我建议您尝试使用Bitnami Trac堆栈。 http://bitnami.org/stack/trac

它简化了为您设置Subversion的过程，附带了一个票务系统（您可以在此阶段选择是否使用）来跟踪更改和错误，还提供一个Wiki，用于记录您希望开发人员使用的方式。系统。

向所有Windows开发人员提供TortoiseSVN。教大家一些svn命令行基础知识。

归根结底，该工具比您需要向开发人员灌输的思维方式重要。希望他们很快会看到版本控制是一件好事，因为它阻止了他们失去工作，并允许他们从死胡同中恢复过来，使他们无处可退回到已知的良好状态。好处超过了（少量）开销。