我在工做中是這樣使用Git

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代碼，而後重複三、4步，checkout B、切換A、merge B。
6. 在 gitlab等私服申請請求合併，merge A into matser，這時絕對不會有衝突產生。
7. 合併到master後 刪除本身的功能分支。
8. 服務器上部署master上線。

爲何有第3步？實際上是爲了第四、第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】不用提交本地文件或者一些帶有我的配置的文件，如.idea文件夾裏的文件。配置文件中ip最好是127.0.0.1，這樣提交時全部人本地都能用，各類中間件的帳號密碼也能夠統一，若是非要用本身的配置，那你就不要提交這些文件到Git上了，否則別人拉項目總有衝突！！！（強烈補充，深受其害）

6 總結

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

做爲一個git的新手，甚至還不知道git是什麼，沒什麼大不了的，如今學學就好。

但若是你同時是一個開發團隊的leader，尚未很好的git管理規範的話，那確實得認認真真去學一下了。

想要獲取更完整的內容可參考廖雪峯老師的git教程

再推薦一個外國小姐姐寫的git命令動圖展現

我們下期見吧！！！！