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… 我的原創文章