很多時候，經驗是被痛苦逼出來的，流程是被錯誤逼出來的。在上線的過程當中，這段時間遇到了一些問題，造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。
另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本，也是有可能的。像我現在的公司，經常一天修改好多次文案，就需要不斷的上線。如果處理不及時上線的話，會造成使用者的一些誤解，導致一些投訴以及不好的使用者體驗。這麼頻繁的修改上線，也是需要一定的流程和規範保證。
很多網際網路公司都開始使用git，替換了svn。git非常適合網際網路迭代以及多人多版本開發。如果讓我說為什麼喜歡使用git，我喜歡切換分支，以及分支之間merge的方便快捷。
新建分支以及合併分支的便利性，會造成一些問題，分支不自然的就會過多。所以需要定時的需要刪除一些過時的分支。
一般來說，網際網路專案有上線分支，預上線分支，測試分支，開發分支等．
保證不同的分支做不同的事情，防止分支汙染。
上線分支，是發布到線上的分支，以這個分支為準，其他分支都是以這個分支為基礎拉取。
預上線分支，在預上線環境當中，防止出錯的最後一道保證。
測試分支，可能測試環境大家共用一套，所以把**都merge到這裡，然後發布。這樣大家各自測試自己的，互不打擾。如果有多個測試環境的話，直接使用開發分支測試也是可以的。
開發分支，從上線分支拉取，根據需求修改的新分支。
上面的這張圖看起來有一點複雜。總體上來，可以分為這麼幾步。
第一步，需求來了之後，從上線分支拉取乙個開發分支。
第二步，在開發分支進行開發，自測。
第三步，合併到測試分支，通知qa測試。
第四步，如果通過測試，合併到預上線分支，然後繼續測試。如果不通過測試，進入第二步。
第五步，如果預上線測試通過，將預上線分支合併到上線分支。如果不通過測試，進入第二步。
第六步，上線，然後線上測試。如果通過測試，那麼這個需求開發就結束了。如果沒有通過測試，就撤回上線，然後進入第二步。
測試分支以及預上線分支要定時清理，和上線分支同步。
上線分支以及預上線分支，merge許可權保證在少數人手裡。merge的時候，需要檢查提交以及對線上的影響。
只能在開發分支修改**，其他分支都是等著被merge.
提交之前，需要保證和上線分支沒有衝突。
防止分支被汙染，特別是受到測試分支汙染。
人是最難管理的，以及人是懶惰的。這些話是非常準確的，所以會遇到一下問題，還得需要解決。
需求改動非常小，是不是還得走整體流程。
我只是修改文案，是不是還得走整體流程。
具體怎麼做，每乙個公司和組都有自己的做法，是不是都必須都得走一遍流程。但是，分支規範是必須的，不能隨意修改。直接在上線分支修改，堅決說no!
說一說，正常上線的流程
很多時候，經驗是被痛苦逼出來的，流程是被錯誤逼出來的。在上線的過程當中，這段時間遇到了一些問題，造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本，也是有可能的。像我現在的公司，經常一天修改好多次文案，就需要不斷的上線。如...
說一說，正常上線的流程
很多時候，經驗是被痛苦逼出來的，流程是被錯誤逼出來的。在上線的過程當中，這段時間遇到了一些問題，造成了研發耽誤了不少時間。原因是上線的不規範性以及沒有任何的許可權限制。另外網際網路專案版本開發都非常頻繁。一天上線十幾個小版本，也是有可能的。像我現在的公司，經常一天修改好多次文案，就需要不斷的上線。如...
簡單的說一說mmap
mmap memory map，就是記憶體對映 簡單的說就是將檔案對映到使用者的位址空間中。這麼做有什麼好處呢？1.傳統檔案訪問方式是,首先用open系統呼叫開啟檔案,然後使用read,write等呼叫進行順序或者隨即的i o.這種方式是非常低效的,每一次i o操作都需要一次系統呼叫.而通過mmap...