1 絮叨 最近因為工作有點忙，加上自己個人生活的一些瑣事，突然感覺寫文章太難了，不過還是慢慢堅持下來，即使更新頻率變慢了。最近的主題還是那個初衷， 記錄下自己日常開發工作的一些想法。

　　2 前言git 在日常的開發工作中，免不了會使用git進行代碼管理，熟練使用git會使我們有更多的時間專注于代碼編寫，加快整體開發效率。 然而對我而言，git隻是工具，一些常規操作已經足夠了，有空有興趣才會去深入研究它。不熟悉git也不要緊，學學就好， 快的話随便看幾個命令後自己再實踐一下就可以應付日常開發了。

　　3 常用Git命令 我日常開發有用idea去操作git，當然有些場景也會在idea的Terminal面闆去手打命令，當你熟悉了之後，簡直是舒服地飛起，會感覺到看似雜亂無章的各個分支裡的代碼，在你幾個命令操作下管理得井然有序。

　　3.1 克隆項目 git clone 從遠程庫拉項目到idea： VCS-Checkout from Version Control-Git，貼上URL後點Clone，idea就會幫我們執行git clone命令。

　　當然，也可以先git clone htt但誰要能保證你即使pull後在到push這一瞬間，有沒有人提交代碼呢？

　　若别人有提交代碼，idea會在你push時提示你要不要merge，若沒有沖突會自動合并，此時git日志裡會有這麼一行記錄 Merge remote-tracking branch origin/dev into dev git的日志記錄也不會是一條完整直線了。若有沖突，需要手動解決。若你先pull，沒沖突當然最好，有沖突你會pull失敗，提示本地修改會被覆蓋。 這時可以git stash 暫存修改。 暫存成功後 git pull拉取代碼。 git unstash将暫存的代碼更新到當前分支上。

　　如果此時有沖突，可手動解決，idea也提供良好的可視化圖形，解決沖突變得容易許多。

　　左邊本地代碼、右邊遠程代碼、中間合并成功之後的代碼

　　3.6 撤銷操作還沒commit就想放棄修改，直接鼠标右鍵點擊文件Revert就好。commit了之後還沒push，想撤回commint前操作。 git reset --hard HEAD~ --hard直接還原到上一版本，不保留修改(慎用) git reset --soft HEAD~ --soft還原到上一版本，保留commit前的修改(常用) git reset --mixed HEAD~ --mixed 與soft不同的是，還原到git add前沒暫存的文件 圖形化 GIt-Repository-Reset HEAD... HEAD~上一版本

　　一般都後悔操作上一步，想回退多步直接指定版本号吧 git reset --hard HEAD commit_id

　　push之後想回退。 依然可以用上述操作，隻不過在下一次push之後，會拿回退前的版本跟當前修改合并，有沖突要解決。3.7 合并代碼 git merge 這裡我一般都是圖形化操作，将遠程代碼合并到自己當前的分支上。

　　merge dev(分支名) into current

　　4 多人開發合作模式 所謂的開發合作模式，簡單來說就是git的分支管理。

　　每個公司因為業務量不同、服務器數量不同，都有自己的管理規範。

　　簡單點的可能隻有主幹master、開發分支dev。

　　複雜點的多了功能分支feature、bug修改分支fixbug，甚至還有測試分支test、預發布分支pre-release。

　　當然，這些不同場景的叫法和命名都是自己定義的，但你的項目再簡單，最好不要簡化到隻有master和dev分支。

　　我曾入職一家公司，看到裡面的項目隻有master和dev，就直接跟當時的開發說你們這樣幹，不會遇到某某問題嗎？沒想到 一語中的，所以後面才規範了分支管理規範。

　　那會有什麼問題？

　　master是線上穩定的代碼分支，一般不能直接在上面修改，這時産品來了2個或以上需求，因進度不同不能同時上線， 這時你們共用一個dev，那豈不是把别人未測試過的代碼給上了？你可能會說我們公司需求不多，上線一個功能才開發下一功能，那自己私下想寫些demo測試優化，還不是要在dev上改？2個功能需求想一起測試、一起上線，那我都在dev開發？最好還是分開，各自建自己的分支開發，避免其他同事在解決沖突時因不熟悉git把你的代碼給幹掉了。後面想一起上線時再一起合并即可。 目前自己在用的管理模式，master 多個feature分支，僅此而已：

　　需求下來，在master上建個功能分支，命名f 時間 功能名，如：f_20200521_coupon(暫且定義A)。本地開發、服務器上測試都直接部署功能分支的代碼。測試通過即将上線時，checkout本地的master，git pull拉最新代碼。再切換回自己的功能分支A，并merge matser into current，手動解沖突。如果想連同他人的分支(暫且定義B)一起上線，最好先叫你的夥伴先合master代碼，然後重複3、4步，checkout B、切換A、merge B。在gitlab等私服申請請求合并，merge A into matser，這時絕對不會有沖突産生。合并到master後删除自己的功能分支。服務器上部署master上線。 為什麼有第3步？其實是為了第4、第6步服務的，得先保證你本地的matser是線上最新的，經過第4步之後去到第6步，因為master是最新且在第4步已解決沖突，到了第6步就絕對不會有沖突。

　　為什麼不直接在第3步後就 merge A into current（master）？為了安全，master一般不能在本地直接操作，是一個受保護的分支。

　　為什麼在第4步merge matser into A後還要在第6步merge A into matser，繞來繞去，在逗我嗎？上面已經回答了，master分支一般是有權限（受保護）的，merge A into matser不能在本地操作，隻能在gitlab（git私服）上操作，但gitlab上又不能手動解決沖突，所以我們要先在本地merge matser into A并手動解決沖突，再到第6步就可以完美合并。

　　是不是被我繞暈了......???

　　另外，遇到線上bug得緊急修複，也能建個功能分支，然後按上述方法操作。

　　如果隻是改的線上的極小功能(文案，簡單判斷之類的)又想快速上線，而且你還有操作matser的權限，那大可不必按上述方式，直接master上改後提交就行，多爽是吧。

　　5 建議 【建議1】一定要在最新的master上新建分支，不然後面上線時會上了别人未測試的代碼。

　　【建議2】做好一個功能點就提交代碼，避免意外事件導緻代碼丢失。和别人一起在同一分支開發時，盡早提交可以不用解決沖突， 把這事留給别人哈哈哈。

　　【建議3】解決沖突時如果不确定會不會處理不當，最好拉上之前寫這段代碼的同事一起看。

　　【建議4】上線合并到master後最好開發群通知一下，讓其他開發同事盡早拉最新master代碼合到自己的分支。

　　【建議5】跟建議4關聯，開發周期較長，應及時将線上最新master合到當前正在開發的分支，避免最後上線前花時間解決大量沖突，同時盡早避免自己依賴的上遊業務被修改而引發新的異常發生。

　　【建議6】不定期的code review。

　　【建議7】......................

　　6 總結 本文介紹了自己平時常用的git命令和一些常規操作、分支管理模式、項目上線規範、日常開發的建議等等，偏向基礎，太難也寫不出，隻是記錄自己平時的工作和一些想法。

　　作為一個git的新手，甚至還不知道git是什麼，沒什麼大不了的，現在學學就好。

　　但如果你同時是一個開發團隊的leader，還沒有很好的git管理規範的話，那确實得認認真真去學一下了。

　　作者：悟空GoKu鍊接：htt