導讀1絮叨最近因為工作有點忙，加上自己個人生活的一些瑣事，突然感覺寫文章太難了，不過還是慢慢堅持下來，即使更新頻率變慢了。最近的主題還是那個初衷，記錄下自己日常....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 https://gitee.com/xxx/Test.git到本地后，在把項目導入idea中

3.2 查看分支 git branch

查看當前項目有哪些分支

3.3 檢出代碼 git checkout

拉取遠程分支代碼

git checkout -b dev(本地分支名稱) origin/dev(遠程分支名稱)

3.4 創建分支 git checkout -b

有時你想自己創建一條分支可執行 git checkout -b dev(分支名)

相當于2條命令

git branch dev

git checkout dev

切記，一定要在最新master分支上創建新分支

3.5 拉取/提交/推送代碼 git pull/git commit/git push

這幾個操作真的是最基本了，相信在所有命令中，熟悉這個的人占極大多數，這里我一般都是借助idea操作的。

如果是多人在同一分支開發的話，一般在push之前要先pull最新代碼，但誰要能保證你即使pull后在到push這一瞬間，有沒有人提交代碼呢？

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

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

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

3.6 撤銷操作

1. 還沒commit就想放棄修改，直接鼠標右鍵點擊文件Revert就好。
2. 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

3. 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分支，僅此而已：

1. 需求下來，在master上建個功能分支，命名f 時間 功能名，如：f_20200521_coupon(暫且定義A)。
2. 本地開發、服務器上測試都直接部署功能分支的代碼。
3. 測試通過即將上線時，checkout本地的master，git pull拉最新代碼。
4. 再切換回自己的功能分支A，并merge matser into current，手動解沖突。
5. 如果想連同他人的分支(暫且定義B)一起上線，最好先叫你的伙伴先合master代碼，然后重復3、4步，checkout B、切換A、merge B。
6. 在gitlab等私服申請請求合并，merge A into matser，這時絕對不會有沖突產生。
7. 合并到master后刪除自己的功能分支。
8. 服務器上部署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鏈接：https://juejin.im/post/5ec7859ae51d45788f0d6cd1