很多時候，經驗是被痛苦逼出來的，流程是被錯誤逼出來的。在上線的過程當中，這段時間遇到了一些問題，造成了研發耽誤了不少時間。原因是上線的不規范性以及沒有任何的權限限制。
另外互聯網項目版本開發都非常頻繁。一天上線十幾個小版本，也是有可能的。像我現在的公司，經常一天修改好多次文案，就需要不斷的上線。如果處理不及時上線的話，會造成用戶的一些誤解，導致一些投訴以及不好的用戶體驗。這么頻繁的修改上線，也是需要一定的流程和規范保證。
Git 代碼管理
很多互聯網公司都開始使用Git，替換了svn。Git非常適合互聯網迭代以及多人多版本開發。如果讓我說為什么喜歡使用Git，我喜歡切換分支，以及分支之間merge的方便快捷。
新建分支以及合並分支的便利性，會造成一些問題，分支不自然的就會過多。所以需要定時的需要刪除一些過時的分支。
項目分支
一般來說，互聯網項目有上線分支，預上線分支，測試分支，開發分支等．
保證不同的分支做不同的事情，防止分支污染。
- 上線分支，是發布到線上的分支，以這個分支為准，其他分支都是以這個分支為基礎拉取。
- 預上線分支，在預上線環境當中，防止出錯的最后一道保證。
- 測試分支，可能測試環境大家共用一套，所以把代碼都merge到這里，然后發布。這樣大家各自測試自己的，互不打擾。如果有多個測試環境的話，直接使用開發分支測試也是可以的。
- 開發分支，從上線分支拉取，根據需求修改的新分支。
開發流程
上面的這張圖看起來有一點復雜。總體上來，可以分為這么幾步。
- 第一步，需求來了之后，從上線分支拉取一個開發分支。
- 第二步，在開發分支進行開發，自測。
- 第三步，合並到測試分支，通知QA測試。
- 第四步，如果通過測試，合並到預上線分支，然后繼續測試。如果不通過測試，進入第二步。
- 第五步，如果預上線測試通過，將預上線分支合並到上線分支。如果不通過測試，進入第二步。
- 第六步，上線，然后線上測試。如果通過測試，那么這個需求開發就結束了。如果沒有通過測試，就撤回上線，然后進入第二步。
分支規范
- 測試分支以及預上線分支要定時清理，和上線分支同步。
- 上線分支以及預上線分支，merge權限保證在少數人手里。merge的時候，需要檢查提交以及對線上的影響。
- 只能在開發分支修改代碼，其他分支都是等着被merge.
- 提交之前，需要保證和上線分支沒有沖突。
- 防止分支被污染，特別是受到測試分支污染。
流程規范之外
人是最難管理的，以及人是懶惰的。這些話是非常准確的，所以會遇到一下問題，還得需要解決。
- 需求改動非常小，是不是還得走整體流程。
- 我只是修改文案，是不是還得走整體流程。
具體怎么做，每一個公司和組都有自己的做法，是不是都必須都得走一遍流程。但是，分支規范是必須的，不能隨意修改。直接在上線分支修改，堅決說NO!
如果轉載的話，請注明轉載地址，萬馬奔騰博客，http://www.woniubi.cn/service_online_process/