作者：joymufeng
來源：https://my.oschina.net/joymufeng/blog/3005221
我們在日常使用Git的程序中經常會發生一些意外情況，如果處理不當，則可能會出現代碼丟失的假象，本文將針對IDEA&Git日常開發中的一些場景，為你層層撥開迷霧，決議常見的錯誤及其發生原因，讓你從此不再懼怕代碼沖突或丟失問題，
為簡化問題，本文假設所有團隊成員均在同一分支上開發，
文中更新操作是指在IDEA中單擊選單VCS-Update Project...，
1. 常見作業流程
通常當你早上到公司打開電腦，首先執行更新操作(單擊IDEA選單VCS-Update Project...)，然后開始愉快地編碼，編碼完成后通常要執行以下幾個操作：
- 更新操作
- 創建本次提交
- 推送遠程分支
1.1 更新操作
為了保證Git擁有一個簡潔的提交歷史，在提交之前需要先執行更新操作，即在IDEA中依次單擊選單VCS-Update Project...，或者按下Ctrl+T，彈出如下視窗：
視窗左側選擇更新型別(Update Type)：
Merge：更新時執行合并操作，等價于執行git fetch && git merge或者git pull --no-rebase，Rebase：更新時執行rebase操作，等價于執行git fetch && git rebase或者git pull --rebase，Branch Default：在.git/config檔案中指定不同分支的更新型別，
視窗右側選擇在更新前作業目錄(Working Directory)的清理方式：
Using Stash：使用git stash儲藏本地修改，Using Shelve：使用IDEA內置的Shelve功能儲藏本地修改，
通常選擇Merge和Using Stash即可，單擊OK后，IDEA執行步驟如下：
- 第1步：使用
git stash儲藏本地修改 - 第2步：執行
git fetch && git merge拉取遠程分支并合并 - 第3步：執行
git stash pop恢復儲藏
有些同學可能更習慣先創建本地提交，然后在執行更新操作，這樣會導致Git自動生成一個合并提交，導致提交歷史不夠簡潔，
1.2 創建本次提交
更新完成后，在IDEA中單擊選單VCS-Commit...創建本次提交，
1.3 推送遠程分支
然后單擊VCS-Git-Push...推送至遠程分支，
2. 常見問題分析
在上面的3步執行步驟中，第2步和第3步發生意外的風險最高，最常見的兩種意外情況是沖突和檔案占用，下面我們分別討論，
2.1 合并遠程分支沖突
如果在執行更新操作之前，你的本地分支已經創建過提交，并且尚未推送至遠程分支，則在第2步執行git merge時很可能會發生沖突，
此時關閉上面的沖突視窗，Version Control工具視窗顯示內容如下：
視窗右下角原本顯示分支名稱的位置變成了Merging master，表示本地分支master目前處于正在合并狀態，單擊左側紅框內Resolve按鈕可以再次調出處理沖突視窗，基于IDEA的圖形界面手動解決沖突后，IDEA會自動將該檔案加入暫存區(加入暫存區即表示沖突解決完成)，最后執行一次提交便可以完成沖突處理，
2.2 恢復儲藏沖突
在更新操作的第3步執行git stash pop恢復儲藏時，儲藏內容可能與剛更新的內容發生沖突，
恢復儲藏時發生的沖突跟上面的合并沖突稍微有些區別，首先是右下角的分支名稱沒有Merging字樣，另外會在右下角額外彈出一個小窗提示恢復儲藏失敗，并且告訴你不用擔心，所有的修改都在stash串列中，并沒有丟失，查看stash串列的方式為單擊選單VCS-Git-UnStash Changes...:
選中串列最上面的條目，然后單擊Apply Stash，之前的修改就會重新回到作業目錄，
我們繼續回到沖突問題，手動解決沖突后執行一次提交就可以了，如果在解決沖突程序中發生了誤操作，可以右擊Default Changelist-Revert...清空當前作業目錄內容，重新執行一次Apply Stash，然后重復解決沖突程序，
2.3 檔案占用錯誤
在執行第2步git merge時，可能會因為檔案被占用導致執行失敗，例如專案可能引入了一些jar檔案，這些jar檔案在本地已經被JVM動態加載了，如果有其它人更新了該jar檔案并且推送到了遠程分支，當你更新時便會遇到上述問題，
對于這種錯誤的解決方法很簡單，首先解除檔案的占用狀態，例如終止本地JVM行程，然后再次點擊VCS-Update，
在執行第3步git stash pop時，也會因為檔案被占用導致執行失敗，例如你更新了某個jar檔案，當恢復儲藏時可能因為該jar檔案被占用導致恢復失敗，
對于這種錯誤，你需要首先解除檔案占用狀態，然后手動執行unstash操作，
3. 先提交還是先更新？是個問題！
3.1 先提交后更新導致的問題
3.1.1 發生沖突時難以處理
如果先提交，但是在更新時卻發生了沖突，這就意味著你剛剛創建的提交其實是有問題的，通常是團隊溝通或是分工出了問題，但是不管這么說，別人已經搶先一步push了，你的提交便會被拒之門外，即便是手動解決了沖突，這個提交保留在歷史中也會成為隱患，如果有其他人reset回這個提交繼續作業，則在合并其它分支內容時發生沖突的概率會大大增加，所以最好處理方式是先撤銷這個提交(reset --soft HEAD~)，然后更新并解決沖突，最后創建一個新的提交，
3.1.2 錯誤的處理沖突方式
在發生沖突后，有些同學可能會想到下面的處理方式：
- 清空當前作業空間
- 調整沖突部分的代碼
- 然后再次執行更新操作
上面的處理方式很明顯是不可行的，因為你調整的代碼首選會被IDEA儲藏（stash）起來，然后在更新的第2步中仍然會發生沖突，并且發生沖突時，你的修改尚未恢復儲藏(unstash)，導致看起來你調整的代碼不見了，讓人摸不著頭腦，
3.1.3 Rebase會改寫提交歷史
如果在IDEA的更新視窗選擇更新型別為Rebase，則等價于手動執行git fetch && git rebase或者git pull --rebase命令，這樣的好處是不會生成一個自動合并提交，保持簡潔的提交歷史，但是需要注意的是，Rebase之后，你的本地提交會被改寫，雖然提交資訊一樣，但是commit hash已經改變了，如下圖所示：
在執行完如下的Rebase命令后，
$ git checkout dev
$ git rebase master
執行結果為：
請注意，結果中的v4和v5提交已經被改寫了，
3.2 推薦先更新后提交
如果你事先知道會發生沖突，相信你一定不會選擇先提交代碼，但是沖突是不可避免的，這就要求我們平時養成良好的開發習慣，與其解決提交后的沖突，不如盡早地解決沖突然后提交，這樣不僅可以減少一個無意義的自動合并提交，而且可以在沖突發生時簡化處理程序，
3.3 養成良好習慣
為了盡量避免沖突發生，建議養成如下開發習慣：
- 編碼前先更新
- 提交前先更新
- 提交前檢查是否有編譯錯誤
- 提交粒度盡可能小，描述盡可能準確
- 修改了公共檔案，盡早通知其他成員更新
- 最后一條，也是最重要的，團隊分工要明確
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/289073.html
標籤：Java