在我上一次的Drupal项目中，我们有5个人在进行编码和安装新模块，我们的客户在同一类型中放置了内容。由于我们选择只有一台服务器是为了简单起见，因此很多人需要写入相同的文件，如style.css或page.tpl.php，或者某些人破坏代码会阻止其他人工作
与Drupal合作的团队是否有最佳实践？如何利用代码存储库或沙箱？
答案 0 :(得分：2)
单个服务器似乎可以为您提供“简单”，但是，正如您所经历的那样，它给您带来的是彻头彻尾的混乱 - 如果它不会导致令人不快和难以复制，那么您很幸运，难以修复的崩溃。不要满足于“生产”服务器（客户可以在哪里工作 - 只有内容 - 如果他们喜欢轻微的风险;-)和“升级”服务器（开发团队的任何东西去在升级到开发之前进行测试并尝试一段时间，这是在安静且理想的预定时间完成的。
其次，使用某种类型的版本控制系统。哪一个比使用一个更重要：svn是流行和简单的，最新的时尚（出于好的理由）是分布式的，如hg和git，微软和其他商业广告在该领域的产品等。
关键是，每当有人更新文件时，他们都会在自己的VCS客户端上这样做。当一组连贯的变化是正确的时，它被推送到VCS，并且VCS诊断并指出任何“冲突”（两个开发人员可能做出相互矛盾的更改的地方），因此当前推动的开发人员负责编辑文件和在推动冲突之前解决冲突是允许的。只有这样，“当前版本”才能在登台系统上进行更彻底（并且理想的自动化！ - ）测试（或者更好的是，“连续构建”系统）。
基本上，对于你观察到的这种冲突应该有两层防御，你似乎也没有部署过。然而，它们都是必不可少的，如果被胁迫只能选择一个，我想我不情愿地选择生产和登台服务器之间的区别 - 开发仍将是混乱的（与任何VCS的简单可靠性相比无法忍受！ ）但至少它不会直接伤害实际的服务系统; - ）。
答案 1 :(得分：0)
这是关于Drupal开发工作流程的精彩文章。它总结了到目前为止在这里回应的所有内容，并添加了“功能”，“强力臂”以及更多的技巧。 http://www.lullabot.com/articles/site-development-workflow-keep-it-code