目錄
Git個人心得體會
git是最常用的代碼版本管理工具，大型項目需要多人協作開發，必須熟用git，如果不知道或者之前不用git，不會通過面試，哪怕是應屆生，不會git儘管基礎很好，競爭力也會降低。git不算什麼技術含量的東西，但是在開發中都會用到。git我個人認爲最重要的是概念，分支的概念，有了概念再和git命令對應起來會有更好的理解，只記住命令沒有分支的概念很難在實踐中運用，況且實踐中大多是可視化工具，命令用到的並不多，但是並不意味着命令不重要。
給大家一個git學習參考的鏈接Pro Git book
成爲git大師（chrome插件翻譯爲中文，真的優秀）
在這裏，我不想講解git怎麼用，也不想記錄視頻中怎麼講。因爲講了看了也還是不會用，還浪費時間，大家去網上找找視頻學習。
爲什麼這麼說呢？我個人的經歷是大半年在操作這個東西，剛接觸git的時候，在網上看git操作教程，一步一步操作理解，就像學習一門語言的時候開始學習基礎語法一樣，當然這可能是不可或缺的步驟，但是我仍然建議大家在學習git的時候一定要去看視頻。我個人學習git的時候看博客，然後再看《GitHub入門與實踐》，然而仍然是紙上得來終覺淺，自己就算想破頭皮都無法舉出真實工作中可能的情況
就是上面這本書，看了一半看不下去了，看了後面忘了前面，直到在工作中不斷的看別人操作，推送，合併，以及在自己的操作錯誤中學習。我是學git命令——看書——工作後實踐中在sourceTree學習（時間長了忘了操作對應的Git命令）——最後看視頻講解對應自己在sourceTree中的操作，感悟深刻。
憑我個人內心話，就看看視頻看看書，就算學的很用功，git真的掌握不了太好
錯誤懵逼記錄： —— 自己在操作當前分支1的時候突然需要切換到分支2去看東西，而在當前分支1新增了A.html，在B中改了一些代碼等等，如果切換到分支2就會提示需要丟棄之前的修改，我就點擊確定，想着丟了就丟了，大不了再寫一遍，結果切換到分支2的時候發現我的A.html還在，咦？我不是丟棄修改了嗎？刪來刪去自己概念都蒙了。等等這些踩坑出錯記錄我得告訴大家，當然，這些操作都是在sourceTree上完成的（可視化git操作工具）
踩坑記錄，主要都是在sourceTree上面操作，這裏記錄命令理解
git stash先存起來，存在儲存區
git stash pop彈出來
新增的文件不用存，存的是在某某文件的修改，切換到另一個分支之後新增的文件還在，只是某某文件的修改丟了，現在再彈出來即可，就可以在這個分支繼續操作上一個分支的內容
Git從開發到上線那些事
※ 拉取最新開發代碼應該怎麼拉取，又如何去推送？
正確做法：從遠端拉取develop分支到本地，然後複製這個分支，比如2.4號拉取的分支命名爲0204/test，就是0204目錄下有叫test的分支，是剛剛develop分支的副本。當然命名是和開發的功能有關的，這樣比較好找，這裏只是舉例用test。
爲什麼不直接將本地的develop改名test呢？如果這樣做就是一個不好的習慣，因爲可能你的develop還跟蹤着遠端的develop，萬一不小心給推送了。。。那可是大家上個版本都經過測試的代碼啊，你將你這個版本還沒測試的代碼合到上個版本的develop分支出問題了呢？如果代碼沒問題還好說，相當於不該你合併代碼的，你幫別人合併了，一旦出問題又得代碼回滾，要是每個人都這樣就瘋了。唉你別笑，我還真這麼搞過一次。刺激不？直接在本地develop分支修改，然後發現遠端develop有最新的，又把遠端develop拉下來合併，合併的時候流程有點不一致，然後辦公司很多人圍着討論這個問題看看是哪裏出問題了，爲啥沒有我的代碼修改記錄，主要是因爲本地合併過一次了，和遠端的develop沒有區別，再給別人合併的時候看不到我代碼哪裏修改了，最後是再加一個空行。就看得到我的代碼修改了。
建議大家不要搞這些不常規的花裏胡哨的操作，最後搞得浪費大家的時間，還慌得一批。
※ 真正的合併應該怎麼合併？
遠程的develop分支拉下來保證最新，你自己push到遠端的分支拉到本地保證最新，然後切換到本地develop分支，將你自己的本地分支合併到develop分支，再將這個develop分支push到遠端同步，這樣下次別人拉取遠端develop的時候就包含了你的最新功能，當然如果測試出有問題你還是需要重新修改提交，然後合併後打包測試，直到沒問題基本說明你開發的這個功能成功，通常這個操作都是由一個專門合併代碼的人完成的，不會讓大家都操作develop合併，這樣容易混亂。就這樣的反覆操作將其他人開發的feature分支（就是每個人開發的分支）一個個合併，再推送到遠端。
關於分支合併的圖形化解釋見這裏：使用Git分支合併文件（如果英文有障礙可以用chrome的翻譯插件）
※ 到上線之前做的事
最後合併完了就從develop分支打出測試包，最後一次develop打出來的就是正式提測包，迴歸測試沒有問題之後等待（否則還需要返工）。。。。。經過代碼走查（一般發版前一天）之後確定沒問題了，就將develop分支合併到release分支，然後打生產內測包和插件，最後運維的人發佈的包和插件是從release分支的代碼裏面打出來的。
PS:各個公司有所不同，我自己在這裏記錄一下
從develop分支打出來的都是 測試包
最後一次develop打出來的就是 正式提測包（最後一次的測試包，還是屬於測試包）
合併到release分支後打出來的包是 生產內測包
生產自測是方便開發人員使用的包，服務器連接的生產環境，插件下載連接的測試環境
生產內測包然後將生產內測包由運維人員發佈到服務器上公開了，這個包就是正式生產包（簡稱生產包），就是大家下載的公開的包
測試包和生產內測包的H5插件都在測試RMS上，只不過目錄不同
測試包:upload/AAAAtest/xx/....../plugins/你的插件包
生產內測包:upload/BBBBtest/xx/....../plugins/你的插件包
測試包用演示環境H5插件包: upload/yanshiTest/xx/....../plugins/你的插件包
可以自動化構建部署，這樣打包和發佈到RMS必須一步完成，後面發包的人需要等待前面一個部署完成。這樣就可以防止多人打包發佈的時候插件被沖掉而要重新打包的問題。
試想有A和B兩個插件方，A去打包平臺打包，上一次插件包是A_1.0.0，這一次新的插件包是A_1.0.1，這樣打包後全局配置文件是A_1.0.1， B_2.0.5(B的上一次版本是B_2.0.5)，這樣app會根據最新的配置文件拉取下載插件包更新(如果有更大的版本，就下載更新)，但是A打包後有點事情，就去接了一杯水喝，準備喝完之後再去RMS部署插件。
但是此時B也在打包平臺打包，打包的時候準備發佈B_2.0.6，然後打包後全局配置文件是A_1.0.1，B_2.0.6
然後B就按照正常流程很快發佈插件包到RMS服務器了，RMS上對應的配置就是A_1.0.1，B_2.0.6（A還沒部署到RMS服務器上呢，要是拉取A_1.0.1直接報錯）
此時打開app會因爲A的插件包拉取不到而報錯，因爲配置文件的A插件包A_1.0.1還沒發到服務器上去呢！！（這就是打包不發插件的直接報錯），如果是登陸插件包，那app直接就進不去了，無法登陸。
接着A喝完水了，馬上去RMS服務器發佈插件包，但是全文配置文件卻是A_1.0.1，B_2.0.5
部署到RMS後，A打開app，根據配置文件正常拉取了新的插件包A_1.0.1，但是別人打開B發佈的插件包功能相關模塊的時候，還是上一個版本的B_2.0.5的功能，因爲雖然發佈了B_2.0.6，但是全局配置文件是B_2.0.5，所以不會拉取最新的。（這就是因爲A打包沒有及時發佈，B發佈到服務器了自己才發佈導致B的插件包無法更新的問題，就是相當於沖掉了B的插件包）
自動部署一步到位纔是王道
我們只要 /dist 目錄中的內容部署到服務器上，客戶端就能夠訪問服務器上的網站和資源。而獲取資源是比較耗費時間的，我們可以通過命中緩存，以降低網絡流量，使網站加載速度更快。（H5插件包都是拉到本地緩存起來，避免每次都去請求資源）。然而，如果我們在部署新版本時不更改資源的文件名，客戶端可能會認爲它沒有被更新，就會使用它的緩存版本。由於緩存的存在，新版本的功能就沒有被獲得。
關注、留言，我們一起學習。
===============Talk is cheap, show me the code================