歡迎光臨
每天分享高質量文章

Git 代碼防丟指南

  • 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中單擊選單VCSUpdate Project...

1. 常見工作流程

通常當你早上到公司打開電腦,首先執行更新操作(單擊IDEA選單VCSUpdate Project...),然後開始愉快地編碼。編碼完成後通常要執行以下幾個操作:

  • 更新操作
  • 創建本次提交
  • 推送遠程分支

1.1 更新操作

為了保證Git擁有一個簡潔的提交歷史,在提交之前需要先執行更新操作,即在IDEA中依次單擊選單VCSUpdate 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功能儲藏本地修改。

通常選擇MergeUsing Stash即可,單擊OK後,IDEA執行步驟如下:

  • 第1步:使用git stash儲藏本地修改
  • 第2步:執行git fetch && git merge拉取遠程分支併合並
  • 第3步:執行git stash pop恢復儲藏

有些同學可能更習慣先創建本地提交,然後在執行更新操作,這樣會導致Git自動生成一個合併提交,導致提交歷史不夠簡潔。

1.2 創建本次提交

更新完成後,在IDEA中單擊選單VCSCommit...創建本次提交。

1.3 推送遠程分支

然後單擊VCSGitPush...推送至遠程分支。

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串列的方式為單擊選單VCSGitUnStash Changes...:

選中串列最上面的條目,然後單擊Apply Stash,之前的修改就會重新回到工作目錄。
我們繼續回到衝突問題,手動解決衝突後執行一次提交就可以了。如果在解決衝突過程中發生了誤操作,可以右擊Default ChangelistRevert...清空當前工作目錄內容,重新執行一次Apply Stash,然後重覆解決衝突過程。

2.3 檔案占用錯誤

在執行第2步git merge時,可能會因為檔案被占用導致執行失敗。例如專案可能引入了一些jar檔案,這些jar檔案在本地已經被JVM動態加載了,如果有其它人更新了該jar檔案並且推送到了遠程分支,當你更新時便會遇到上述問題。

對於這種錯誤的解決方法很簡單,首先解除檔案的占用狀態,例如終止本地JVM行程,然後再次點擊VCSUpdate

在執行第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

執行結果為:

請註意,結果中的v4v5提交已經被改寫了。

3.2 推薦先更新後提交

如果你事先知道會發生衝突,相信你一定不會選擇先提交代碼,但是衝突是不可避免的,這就要求我們平時養成良好的開發習慣。與其解決提交後的衝突,不如儘早地解決衝突然後提交,這樣不僅可以減少一個無意義的自動合併提交,而且可以在衝突發生時簡化處理過程。

3.3 養成良好習慣

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

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

分享創造快樂