大约100个网站的功能.我们在一个独立的开发和生产环境中运营了几年
这工作得相当好.总是有足够的独立功能可供开发,程序员永远不会真正发生冲突
没有源代码控制工作更方便;即使它有数据丢失的风险,我们也有相同的文件份额
在一次不经意的举动中失踪.
另一个考虑因素是我们的设计师并不精通技术(我将它们介绍给html
标记,而不是使用WYSIWYGs).这是犹豫是否要转向版本控制的原因之一.
但是,现在我们已经达到了100个站点并且开发团队正在发展,我正在尝试标准化我们的程序和源代码控制
对程序员而言似乎是合乎逻辑的一步.我希望这也会加快我们的补丁部署速度.
不幸的是,我在设置源控制系统方面的经验非常有限.
我很想知道有类似设置的人或者切换经验的人：
1)您是否对所有内容(网站,CSS,HTML模板和应用程序代码)进行了版本控制,从而迫使设计人员学习版本控制？或者只是开发人员处理应用程序代码？
2)在初始设置源代码管理时需要注意哪些陷阱？
3)部署dev =>源控制的生产技巧.
感谢所有的见解.
编辑1：Dang.到目前为止,每个人都建议控制一切.这会让我早早失去我的头发.它可能会在不久的将来引发一个新问题.感谢您的建议到目前为止,保持它的到来！
编辑2：很多好的答案,我们将研究各种版本控制系统.感谢大家的回复！
如果你刚刚开始,我强烈建议使用像git或mercurial这样的distributed version control system.这是世界上的大趋势,并且有很多优点.它很容易在断开连接模式下工作,没有网络依赖性,并且能够在版本控制下进行私有的,未完成的工作,在准备就绪时集中检查所有内容.
并且,不要诉诸权威或任何东西,但请查看Joel Spolsky has to say on the topic.(选择引用：“Subversion = Leeches.Mercurial和Git = Antibiotics.”)除此之外,他提出这些新系统的有趣观点使用一种新的心理模型,不同于传统的版本控制 – 这就是为什么从一开始就采用这种方法是一种胜利.
原文地址：https://www.jb51.cc/php/139752.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
