問題是git commit --amend 引起的。 一條commit已經push到遠端develop了，但是後來又在這條commit上進行了amend操作，導致這條commit的雜湊碼發生了變化。並且後續又在這條commit之後進行了n條commit操作。
大概的情況畫了個簡圖，如圖所示。下面的綠色就是最後相同的地方，紅色的那條做的是相同的功能message是一樣的，但是提完develop之後又改動了很多然後使用amend擠壓了。
這個時候比較頭疼了，因為那條amend的commit裡面是發生了太多改動，我採用的是可以避免衝突的方法，但是會改develop的commit樹
git checkout developgit reset 2c4532 //上面97，98，99的改動會被放出來
git stash //先把這些改動存起來
git reset --hard 5d67bc //等於是把96完全剔除了，**回到了95的狀態
git cherry-pick 8a6f7f //把那一條修改後的功能commit（96的feature）貼上過來，這一步100%不會有衝突
git stash pop //把之前存起來的那些改動再放出來，這一步不能保證100%無衝突，但實際由於兩個功能模組離得比較開，所以也沒有發生衝突。
git add . git commit -m " " //把develop上面的97，98，99三條commit 擠壓成了一條後commit
git cherry-pick 86f6cc d34c7 2817f5 //這一步把feature分支的97，98，99三條commit貼上過來，因為這三條基本是基於8a6f7f開發的，所以也沒有發生衝突。 董鉑然
這樣改完之後develop的commit樹如上圖所示（第97條就是把之前的97，98，99擠壓成的1條），可以編譯通過功能都能實現。 但是缺點是這時候需要強推develop了。
組裡另乙個人提出的解決方案是
（圖再貼一遍 省的往上翻）
git checkout feature //操作都在feature分支進行，不動develop的**git reset 5d67bc //把feature分支上「不科學」的commit 96，97，98，99 全部放出來
git stash //全部臨時存起來
git rebase develop //快進一下，合入了所有develop的新** 100%無衝突
git stash pop //把之前揉在一起的4條commit的**一起放出來，這時候會有大量衝突。
git add . git commit -m "fix" //解決衝突後commit一下
//然後再把最後的一條commit merge入develop，最後的結果時develop如下
可以看出這種做法，不需要強制push develop的**。理論上更加科學，但是中間需要解決大量的衝突。
事後反省一下，覺得兩種方法其實各有優劣，如果組內成員不多，可以在大家的監督下 完成強推develop的操作。 因為解決了大量衝突可能會比 非常清晰了解差異後-f強推develop更容易出現錯誤。 當然如果是大型專案，幾十人團隊，並且遠端都綁上了編譯檢查，和merge規則的專案也只能使用第二種方法了。
對於乙個碼農而言，比寫出bug更恐怖的是把**弄丟了或弄亂了。 對於這種問題也是有一種統一的解決方案
①.git reset --hard 雜湊碼 ， 這條非常普遍，如果出現問題有點亂直接回到乙個安全的commit
②.git reflog 對於有rebase或merge這種操作，第一條指令就用不了了，因為被汙染的並不僅僅是最後一條commit。 這時要用這個萬能恢復指令，回到乙個操作的雜湊碼。
③.但是前兩種方法都是對於一些已經加入過git的**進行恢復。 如果一些**還沒有commit 這時候弄丟了 那些指令就都幫不了你了。 這時候只能看ide有沒有local history了。(local history相當於ide幫你實現了乙個類似於git的功能)之前就有過一次第3種情況的經歷，當時是把沒commit的**給reset了 使用localhistory得以恢復。好在現在ios的xcode 和 android的android studio都是有local history的，
如果上文說的問題有更好的解決方案，也歡迎一起討論。
記一次伺服器事故
mysql資料庫報錯 can t create write to file tmp sql 6ccc 0.myi 在開始刪除之後，所有服務就已經恢復正常執行了，接下來就是優化那個session了，哎又是埋坑.最後附上inode擴容的方法 但是需要注意，手動擴inode，一般是新建分割槽時設定的，該操...
記一次慢查詢引發的事故
首先，測試環境上線新版本，並且通過黑盒測試以及功能測試。然後，我們就上線了新的版本。但是在執行3天後，整個伺服器大部分介面都失效了，基本上都是timeout。檢查伺服器情況 cpu基本上佔滿了。接著查了資料庫狀態，通過mysql命令show processlist 存在大量的waiting for ...
記生產上的一次事故
問題描述 生產環境上，使用者在登入登出時跳轉到了空白頁面，觀察位址列發現由原本的https變成了http，但是在測試環境上sit uat都是正常的。生產環境的部署大致是這樣子 ssl nginx f5 應用，在訪問ssl的時候請求是https，到了nginx請求就已經變成了http，proxy re...