建站
咨詢
售后
建站咨詢
新聞中心
我們在日常使用Git的過程中經(jīng)常會發(fā)生一些意外情況，如果處理不當(dāng)，則可能會出現(xiàn)代碼丟失的假象。本文將針對IDEA&Git日常開發(fā)中的一些場景，為你層層撥開迷霧，解析常見的錯誤及其發(fā)生原因，讓你從此不再懼怕代碼沖突或丟失問題。
為簡化問題，本文假設(shè)所有團(tuán)隊成員均在同一分支上開發(fā)。
文中更新操作是指在IDEA中單擊菜單VCS-Update Project...。
1、常見工作流程
通常當(dāng)你早上到公司打開電腦，首先執(zhí)行更新操作(單擊IDEA菜單VCS-Update Project...)，然后開始愉快地編碼。編碼完成后通常要執(zhí)行以下幾個操作：
- 更新操作
- 創(chuàng)建本次提交
- 推送遠(yuǎn)程分支
1.1 更新操作
為了保證Git擁有一個簡潔的提交歷史，在提交之前需要先執(zhí)行更新操作，即在IDEA中依次單擊菜單VCS-Update Project...，或者按下Ctrl+T，彈出如下窗口：
窗口左側(cè)選擇更新類型(Update Type)：
- Merge：更新時執(zhí)行合并操作。等價于執(zhí)行g(shù)it fetch && git merge或者git pull --no-rebase。
- Rebase：更新時執(zhí)行rebase操作。等價于執(zhí)行g(shù)it fetch && git rebase或者git pull --rebase。
- Branch Default：在.git/config文件中指定不同分支的更新類型。
窗口右側(cè)選擇在更新前工作目錄(Working Directory)的清理方式：
- Using Stash：使用git stash儲藏本地修改。
- Using Shelve：使用IDEA內(nèi)置的Shelve功能儲藏本地修改。
通常選擇Merge和Using Stash即可，單擊OK后，IDEA執(zhí)行步驟如下：
- 第1步：使用git stash儲藏本地修改
- 第2步：執(zhí)行g(shù)it fetch && git merge拉取遠(yuǎn)程分支并合并
- 第3步：執(zhí)行g(shù)it stash pop恢復(fù)儲藏
有些同學(xué)可能更習(xí)慣先創(chuàng)建本地提交，然后在執(zhí)行更新操作，這樣會導(dǎo)致Git自動生成一個合并提交，導(dǎo)致提交歷史不夠簡潔。
1.2 創(chuàng)建本次提交
更新完成后，在IDEA中單擊菜單VCS-Commit...創(chuàng)建本次提交。
1.3 推送遠(yuǎn)程分支
然后單擊VCS-Git-Push...推送至遠(yuǎn)程分支。
2、常見問題分析
在上面的3步執(zhí)行步驟中，第2步和第3步發(fā)生意外的風(fēng)險最高，最常見的兩種意外情況是沖突和文件占用，下面我們分別討論。
2.1 合并遠(yuǎn)程分支沖突
如果在執(zhí)行更新操作之前，你的本地分支已經(jīng)創(chuàng)建過提交，并且尚未推送至遠(yuǎn)程分支，則在第2步執(zhí)行g(shù)it merge時很可能會發(fā)生沖突。
此時關(guān)閉上面的沖突窗口，Version Control工具窗口顯示內(nèi)容如下：
窗口右下角原本顯示分支名稱的位置變成了Merging master，表示本地分支master目前處于正在合并狀態(tài)。單擊左側(cè)紅框內(nèi)Resolve按鈕可以再次調(diào)出處理沖突窗口?；贗DEA的圖形界面手動解決沖突后，IDEA會自動將該文件加入暫存區(qū)(加入暫存區(qū)即表示沖突解決完成)，最后執(zhí)行一次提交便可以完成沖突處理。
2.2 恢復(fù)儲藏沖突
在更新操作的第3步執(zhí)行g(shù)it stash pop恢復(fù)儲藏時，儲藏內(nèi)容可能與剛更新的內(nèi)容發(fā)生沖突。
恢復(fù)儲藏時發(fā)生的沖突跟上面的合并沖突稍微有些區(qū)別，首先是右下角的分支名稱沒有Merging字樣，另外會在右下角額外彈出一個小窗提示恢復(fù)儲藏失敗，并且告訴你不用擔(dān)心，所有的修改都在stash列表中，并沒有丟失。查看stash列表的方式為單擊菜單VCS-Git-UnStash Changes...:
選中列表最上面的條目，然后單擊Apply Stash，之前的修改就會重新回到工作目錄。
我們繼續(xù)回到?jīng)_突問題，手動解決沖突后執(zhí)行一次提交就可以了。如果在解決沖突過程中發(fā)生了誤操作，可以右擊Default Changelist-Revert...清空當(dāng)前工作目錄內(nèi)容，重新執(zhí)行一次Apply Stash，然后重復(fù)解決沖突過程。
2.3 文件占用錯誤
在執(zhí)行第2步git merge時，可能會因為文件被占用導(dǎo)致執(zhí)行失敗。例如項目可能引入了一些jar文件，這些jar文件在本地已經(jīng)被JVM動態(tài)加載了，如果有其它人更新了該jar文件并且推送到了遠(yuǎn)程分支，當(dāng)你更新時便會遇到上述問題。關(guān)注微信公眾號「web_resourc」,回復(fù) Java 領(lǐng)取2019最新資源。
對于這種錯誤的解決方法很簡單，首先解除文件的占用狀態(tài)，例如終止本地JVM進(jìn)程，然后再次點擊VCS-Update。
在執(zhí)行第3步git stash pop時，也會因為文件被占用導(dǎo)致執(zhí)行失敗。例如你更新了某個jar文件，當(dāng)恢復(fù)儲藏時可能因為該jar文件被占用導(dǎo)致恢復(fù)失敗。
對于這種錯誤，你需要首先解除文件占用狀態(tài)，然后手動執(zhí)行unstash操作。
3、先提交還是先更新?是個問題!
3.1 先提交后更新導(dǎo)致的問題
3.1.1 發(fā)生沖突時難以處理
如果先提交，但是在更新時卻發(fā)生了沖突，這就意味著你剛剛創(chuàng)建的提交其實是有問題的，通常是團(tuán)隊溝通或是分工出了問題，但是不管這么說，別人已經(jīng)搶先一步push了，你的提交便會被拒之門外。即便是手動解決了沖突，這個提交保留在歷史中也會成為隱患，如果有其他人reset回這個提交繼續(xù)工作，則在合并其它分支內(nèi)容時發(fā)生沖突的概率會大大增加，所以最好處理方式是先撤銷這個提交(reset --soft HEAD~)，然后更新并解決沖突，最后創(chuàng)建一個新的提交。
3.1.2 錯誤的處理沖突方式
在發(fā)生沖突后，有些同學(xué)可能會想到下面的處理方式：
- 清空當(dāng)前工作空間
- 調(diào)整沖突部分的代碼
- 然后再次執(zhí)行更新操作
上面的處理方式很明顯是不可行的，因為你調(diào)整的代碼首選會被IDEA儲藏(stash)起來，然后在更新的第2步中仍然會發(fā)生沖突，并且發(fā)生沖突時，你的修改尚未恢復(fù)儲藏(unstash)，導(dǎo)致看起來你調(diào)整的代碼不見了，讓人摸不著頭腦。
3.1.3 Rebase會改寫提交歷史
如果在IDEA的更新窗口選擇更新類型為Rebase，則等價于手動執(zhí)行g(shù)it fetch && git rebase或者git pull --rebase命令。這樣的好處是不會生成一個自動合并提交，保持簡潔的提交歷史。但是需要注意的是，Rebase之后，你的本地提交會被改寫，雖然提交信息一樣，但是commit hash已經(jīng)改變了，如下圖所示：
在執(zhí)行完如下的Rebase命令后，
執(zhí)行結(jié)果為：
請注意，結(jié)果中的v4和v5提交已經(jīng)被改寫了。
3.2 推薦先更新后提交
如果你事先知道會發(fā)生沖突，相信你一定不會選擇先提交代碼，但是沖突是不可避免的，這就要求我們平時養(yǎng)成良好的開發(fā)習(xí)慣。與其解決提交后的沖突，不如盡早地解決沖突然后提交，這樣不僅可以減少一個無意義的自動合并提交，而且可以在沖突發(fā)生時簡化處理過程。
3.3 養(yǎng)成良好習(xí)慣
為了盡量避免沖突發(fā)生，建議養(yǎng)成如下開發(fā)習(xí)慣：
- 編碼前先更新
- 提交前先更新
- 提交前檢查是否有編譯錯誤
- 提交粒度盡可能小，描述盡可能準(zhǔn)確
- 修改了公共文件，盡早通知其他成員更新
- 最后一條，也是最重要的，團(tuán)隊分工要明確
網(wǎng)頁標(biāo)題：Git代碼防丟指南
本文鏈接：http://m.5511xx.com/article/djggidg.html
