• 1. 常見工作流程
  • 1.1 更新操作
  • 1.2 建立本次提交
  • 1.3 推送遠端分支
• 2. 常見問題分析
  • 2.1 合併遠端分支衝突
  • 2.2 恢復儲藏衝突
  • 2.3 檔案佔用錯誤
• 3. 先提交還是先更新？是個問題！
  • 3.1 先提交後更新導致的問題
  • 3.2 推薦先更新後提交
  • 3.3 養成良好習慣

---

我們在日常使用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 養成良好習慣

為了儘量避免衝突發生，建議養成如下開發習慣：

• 編碼前先更新
• 提交前先更新
• 提交前檢查是否有編譯錯誤
• 提交粒度盡可能小，描述盡可能準確
• 修改了公共檔案，儘早通知其他成員更新
• 最後一條，也是最重要的，團隊分工要明確