一般操作都是把遠端倉庫同步到本地【git pull】
然後，在在本地做修改，修改好了然後提交到遠端。同步操作應該是【新增】操作。
但是，有一種特殊情況，就是
a，b同時對遠端倉庫做了git pull，且a、b都做了修改。
此時b提交了？那麼a還能繼續提交嗎？
使用者a：
使用者b：
解析：從b使用者的提交中大致可以知道：提交被拒絕，因為遠端分支有一些內容是你本地沒有的。
所以，這個道理告訴我們要建立分支！！！
好，我們接著幫b使用者去解決他遇到的問題：
方法一：b使用者現在去建立乙個分支，然後提交，再merge到主分支
方法二：b使用者直接強制提交【git push -f】，這個就比較暴力了，a使用者提交的內容將會消失。【不建議這樣做】
//注：f<=>force強制
20200816修改：
應該有方法三的存在：就是先pull**，然後再提交，這個也是多人在同乙個分支修改**的基本流程。
只要不出現改同乙個檔案的情況，就可以正常pull下來，然後再提交即可。
如果出現了修改同乙個檔案的情況，可以先複製乙份這個衝突檔案到本地，然後git checkout 檔名 撤銷修改，然後再pull別人的**，接下來再提交，提交成功後，再去修改那個檔案即可。
方法一的merge操作，應該是等同於先pull然後push的。merge操作，只要不出現同乙個檔案修改，對於a,b使用者各自新增的檔案是可以合併的。所以感覺merge的是平級的分支，push的是遠端分支和遠端分支在本地的副本。
暫時是這樣理解的，有待驗證...
現在，我們通過建立分支去解決這個問題：
最後，在回到主分支把**pull下來就能看到兩個檔案了！
接著往後說一點：
現在，刪除乙個檔案，顯然是可以的。只要你當前的狀態與遠端分支一致，就可以正常增、刪、改。這也是為什麼要先pull遠端分支，然後再操作。
然後，我們再來看下，使用者b強制提交的實驗：
a,b都是與主分支同步。
a使用者，提交了乙個自己的檔案
此時，我們的b使用者，不pull**，然後提交，提交肯定是失敗了，所以我們用git pull -f強制提交【由於master是保護分支，所以先去網頁版取消了保護】
最終可以看到遠端分支的內容
我們為什麼要分庫分表
本文 當一張表的資料達到幾千萬時，查詢一次所花的時間會變長。這時候，如果有聯合查詢的話，可能會卡死在那兒，甚至把系統給拖垮。而分庫分表的目的就在於此 減小資料庫的負擔，提高資料庫的效率，縮短查詢時間。另外，因為分庫分表這種改造是可控的，底層還是基於rdbms，因此整個資料庫的運維體系以及相關基礎設施...
為什麼我們要放棄Subversion
subversion 曾經是我們親密無間的戰友，但自 從一年前部分團隊成員去了美國，我們和subversion的關係就開始出現了裂痕，首先是將subversion伺服器架設在美國後，中國開發人員頻繁 進行的一些操作變得非常緩慢，本來通過追溯 歷史便可找出原因的問題，卻因為網速緩慢，導致開發者將大量的...
我們為什麼要思考演算法
源頭 演算法 的中文最早出現在中國漢代的數學名著 周髀算經 中。周髀算經 卷上有 數之法出於圓方。圓出於方，方出於矩。矩出於九九八十一 意思是 算數的方法都出於對圓 對方的計算，其中圓出於方 圓形面積 外接正方形x圓周率 4 方出於矩 正方形源自兩邊相等的矩 矩的計算出於九九八十一 長乘寬面積的計算...