Git 如何遺棄已經(jīng) push 的提交抚垃，處理方法應(yīng)該更新到文章：Git 如何遺棄已經(jīng) Push 的提交
以下是原文：
最近也是終于開啟了代碼編寫之旅琢感，我只能默默地說一句玩裙，寫代碼的感覺叹哭，簡直不能再爽勤揩！
不過也由于 git 的分支管理蛋疼懵逼很久俗批，所以必須記錄以及和大家分享一下本次坑爹的旅行俗或。
寫在前面
每個公司相比都有自己的 git 分支管理規(guī)范，在項目組中開發(fā)人員較多的時候岁忘，這個就顯得尤為重要辛慰。所以我們必須得掌握 git 的分支管理「上瘢基本套路就是有一個主線帅腌，然后在迭代周期內(nèi)，每個開發(fā)人員拉取自己的分支麻汰，待開發(fā)完畢后大家再 merge 回主線狞膘，發(fā)布版本。
具體的 git 代碼分支管理看這個好了：https://nvie.com/posts/a-successful-git-branching-model/
怎么回事什乙？
到底怎么就被 git 版本回滾給坑了呢挽封？不急，待我慢慢道來臣镣。
在咕咚的項目組中辅愿，在一個新的需求評審?fù)戤叄M入開發(fā)狀態(tài)時忆某，大家會基于 develop 分支拉取自己的分支点待，命名為 feature/XXX，然后各自在自己的分支上進行開發(fā)弃舒。
由于大家開發(fā)業(yè)務(wù)上的不同癞埠，所以在需求開發(fā)完畢状原，整合代碼的時候，一般都不會出現(xiàn)沖突的情況苗踪，即使出現(xiàn)颠区，那也應(yīng)該是比較容易解決的。
可在最近的一次 merge 中出現(xiàn)了一個比較奇怪的問題通铲。
如圖所示：
我當前所在的分支是 feature8.29.0_nanchen毕莱，該分支已經(jīng) merge 了 release8.28.0 分支上的最新代碼，本地沒有任何提交÷幔現(xiàn)在由于一些原因朋截，我需要把另外一位同事開發(fā)的 feature8.28_buyGifts 分支代碼合并到我的分支上。進行開發(fā)吧黄。
意外地出現(xiàn)了很多的沖突部服。
我們使用 git status 看看到底發(fā)生了什么。
從截圖中可以看出拗慨，git 認為我們當前的分支 delete 了不少文件廓八，而這些文件是在 feature8.28_buyGifts 分支上存在的。
我們 vim 查看文件情況胆描。這里就選取第一個 MarketItemsInfo.java 做截圖。
我們查看其他沖突文件以后仗阅，發(fā)現(xiàn)全部是和 Presents 這個類相關(guān)的沖突昌讲，而這些文件實際上是開發(fā) feature8.28_buyGifts 分支的小伙伴開發(fā)的，主分支不可能做干預(yù)减噪，這里讓人什么疑惑短绸。
為了驗證自己的猜想，我們查看一下 MarketItemsInfo.java 的提交歷史筹裕。
正如我們所想醋闭，確實在 7 個月內(nèi)，都沒有人動過這個文件朝卒。
所以一個 7 個月都沒有人動過的文件证逻，怎么就會 merge 的時候出現(xiàn)了這個令人費解的沖突呢？
查看一下當前分支所有的日志抗斤。
似乎發(fā)現(xiàn)了一點異常囚企。這位小伙伴曾經(jīng)往 release8.28.0 進行了 merge 操作，此后被告知未提測不能 merge 到主線的時候瑞眼，他又對 release8.28.0 分支做了 revert 操作龙宏。所以可能因此讓 git 認為 release8.28.0 上有了這樣的文件修改，因為操作后面被 revert伤疙，所以用 git lg <fileName> 的時候银酗，也看不到最近對文件的改動記錄。
我現(xiàn)在只能說可能是這個原因，如果大家有高見的還望留言指導(dǎo)黍特。
如果是這樣蛙讥，那么我們只要在此次 revert 操作之前進行 merge feature8.28_buyGifts 分支代碼的話，應(yīng)該是不會出問題的衅澈。
為了驗證键菱，我們重新建立一個分支，然后 reset 到 revert 操作之前今布，再進行 merge经备，查看是否還會出現(xiàn)這樣的情況。
明顯沒有出現(xiàn)任務(wù)沖突部默。
我們再試試侵蒙，在 revert 后進行 merge 操作。
如我們所想傅蹂，當我們 reset 到 revert 提交的時候纷闺，再進行 merge 直接發(fā)生了這個沖突。
這樣的話份蝴，一定意義上犁功，已經(jīng)印證了我們的想法。git 確實把這個文件當做修改了婚夫。
怎么處理浸卦？
遇到了這樣的問題，直觀上案糙，肯定是將沖突的改動限嫌，全部以這位小伙伴的代碼為準，因為主線上的代碼时捌，已經(jīng)確認是沒有人動過這幾個文件的怒医。
最不濟的方法，可能就是直接舍棄掉這個小伙伴的操作奢讨，然后強行把他后面寫的代碼稚叹，重新寫一遍了（因為他后面的代碼量很少）。
為什么會出現(xiàn)這個 revert 操作拿诸？
說到底還是此次 revert 惹的禍入录。
我詢問該小伙伴后，得知佳镜，他是在 release8.28.0 主分支上 merge 了自己的代碼僚稿，并且 push 到服務(wù)器后，被告知未提測的代碼不能 merge 到主分支后蟀伸，希望遺棄 push 到服務(wù)器上的這個 merge 操作蚀同，所以才采用 revert 命令的缅刽。
正確的操作？
我寫這個正確的操作題目蠢络，是真的不敢寫的衰猛。不過還是斗膽寫了一下。如果我想遺棄自己 push 到服務(wù)器上的提交的話刹孔，我一定會選擇 reset 后再進行 push 操作的啡省。
- 首先使用 git reset —hard <版本號> 讓 HEAD 指針指向 merge 前的 commit ID。(注意髓霞，這是直接放棄之后所有的提交卦睹，采用 --hard，這里因為是沒有別人提交別的代碼)
- 再使用 git push origin <分支名> —force 命令強行把提交 push 到服務(wù)器即可方库。
寫在最后
實際上结序，我自己對 git 的操作也有些模棱兩可，不過還是希望能用本次教訓(xùn)給大家簡單做下交流吧纵潦。
