代码迭代的几种方式

1. 直接替换代码
这种适用于自己的博客，多数是托管在虚拟空间上，没有git一类的进行版本管理，一些很技术很低端的公司，也会这样进行迭代，在测试服务器上，数据正常了，然后在正式服务器上，直接覆盖代码，完成版本迭代。

这样做除了增加自信，省时间，其他的基本都没什么好处，不推荐。

延伸： 你甚至可以在服务器上，复制一份正式用的代码，到一个htdocs下的新目录，然后用一个端口或者新域名指向这个目录，将准备迭代的代码覆盖到这个目录，测试没有bug之后，在可以复制到正式的目录，或者直接用apache/nginx指向此目录。

2. git进行分支控制

在测试服务器上，甚至是其他git仓库，开发人员在本地开发，测试，然后将代码提交到仓库中，在正式服务器上，也有一个git，有两个分支，用户访问的正式文件目录是master分支，然后有一个develop分支，从develop分支远程pull代码，再将develop分支的代码合并到master分支，如果有bug，小bug可以在本地修复，执行相同流程进行合并到master分支，完成修复，如果有大型bug，可以回滚代码，修复之后，执行相同的合并流程，完成更新。

延伸： git是一种很强大的工具，可以有更多应用，参加Git Flow http://blog.jobbole.com/76867/
高度使用git flow能解决更多情况，例如上线一个版本之后，下一个迭代计划开发10个功能，在开发了2.5个功能的时候，线上代码发现bug，需要修复，这种情况下，我们不能将开发中的2.5个功能合并到线上，所以单纯的develop/master分支不能满足需要，git flow可以解决这样的问题。

3. nginx分发一部分流量，灰度上线
在大流量的网站，一般是多台服务器，此时可以使用其中一台服务器，进行灰度上线，即将代码提交到此服务器，然后使用nginx/apache控制，分发一部分流量到此服务器，检测代码运行情况和日志，如果有bug,可以继续用nginx/apache将流量从此台服务器关停，修复bug之后，继续给此服务器分发流量，无bug情况下，整体更迭。

其他我也不太熟悉了，这几种情况都可以进行很多详细的操作和权限管理，防止破坏或者操作失误导致问题。

来自http://river0314.lofter.com/p... 我的原创文章