此篇文章只是一篇傻瓜式的，記錄工作中比較規范且常見的一個git工作流需要用到的命令，讓你可以快速的開始工作。而不是一些長篇大論的理論知識，如果你有用過sourcetree或者其它圖形化工具，結合你正在使用的工具，敲這些命令，看圖形化工具中的變化，對比思考這些命令可能會更容易吸收。
1.基本配置
剛入職公司開始做項目拉代碼，需要經歷的第一件事。配置個人的用戶名稱和電子郵件地址（通常是公司郵件地址）
1.1 配置用戶名和郵箱
git config --global user.name "你的名字"
git config --global user.email "你的郵箱"
1.2 設置public key
首先需要在本地生成key
ssh-keygen -t rsa -C "你的郵箱"
一路回車，接下來復制public key
cat ~/.ssh/id_rsa.pub
當然也可以去系統里找到這個文件自己手動復制，
windows用戶，文件一般在
C:\Users\Administrator\.ssh\id_rsa.pub
mac用戶，文件在
用戶名\.ssh\id_rsa.pub
可以在命令行里輸入
open ~/.ssh
有可能你的[用戶名]目錄下只有[公共, 圖片, 文稿, 下載, 音樂，影片] 等這類文件夾，你就可以同時按下 shift command . 三個鍵，就可以看到里面會有一個 .ssh 文件夾了。
還有可能你的文件夾目錄甚至都沒有[用戶名]這一欄，可以按照 訪達 --> 偏好設置 --> 邊欄 中勾選你的用戶名就好了。
扯遠了，回到主題。復制好 .ssh 下的 id_rsa.pub 文件后，打開你的gitlab 或者 其它你們公司用的git倉庫管理系統，將它添加到你的賬戶上
右上角點擊頭像 --> 點擊settings --> 點擊 SSH KEYS --> 點擊 ADD SSH KEYS --> 將獲取的 id_rsa.pub 文件內容粘貼於此
2.開發階段的實際場景與常用命令
2.1 如果是啟動一個新項目，組長需要做什么？
// 2.1.1：新建gitlab倉庫，復制ssh倉庫地址
// 2.1.2：克隆項目到本地文件夾
git clone "復制的地址"
// 2.1.3：此時默認是在maser分支上，進到拉取的本地項目目錄中去，將本地倉庫與遠程倉庫關聯起來。
git remote add origin '復制的地址'
// 2.1.4：推送本地master分支到遠程master分支
git push -u origin master
// 2.1.5：新建一個本地dev分支，並切換到本地dev分支
git checkout -b dev
// 2.1.6：在此之前遠程是沒有dev分支的，需要推送本地dev分支到遠程dev分支
git push -u origin dev
master分支將來控制着發布到線上的穩定版本代碼，普通成員不可以對master分支進行操作，不然每個組員改點東西，很有可能把線上代碼搞崩。組員們只能在dev分支上進行操作。
2.2 接下來組員們需要做什么
// 組員小智：
// 2.2.1 將組長建好的倉庫克隆到本地
git clone "復制的地址"
// 2.2.2 默認在master分支上，需要檢出遠程dev分支到本地dev
git checkout -b dev origin/dev
// 2.2.3 不直接在本地dev分支上寫代碼，不然就跟svn沒什么兩樣了，基於本地dev分支建一個自己的本地分支，名為xiaozhi
git checkout -b xiaozhi dev
// 2.2.4 此時，就切換到了本地xiaozhi分支上，開始寫功能，比如task0001，寫完后
git status
// 查看你本地做了哪些修改
git add '修改的文件名（包含目錄）'
// 或者
git add *
// 來把你的修改添加到暫存區去，接下來提交代碼到本地xiaozhi分支
git commit -m "task0001：基礎布局功能"
// 2.2.5 建議每完成一個任務的其中一個小功能就重復一次2.2.4步驟，每天下班前至少要合並推送一次到dev分支。確保你的代碼不能影響別人的運行，也不會跟最新的代碼相差太遠。首先，切換到本地dev分支
git checkout dev
// 2.2.6 拉取最新dev分支代碼，可能在你寫task0001的時候，別人提交過代碼了
git pull
// 2.2.7 合並本地xiaozhi分支代碼到本地dev分支
git merge xiaozhi
// 2.2.8 推送你改動的代碼到遠程dev分支
git push
// 2.2.9 切換到本地xiaozhi分支
git checkout xiaozhi
// 2.2.10 合並本地dev分支到本地xiaozhi分支
git merge dev
// 至此，你將你的改動推送到了遠程，你的本地也是最新代碼了，繼續去做task0003。重復2.2.4-2.2.10步驟
...
...
...
// 當你在2.2.1步驟的時候，可能你的同事小狒也要開始做task0002，他在他的電腦上又是怎么操作的呢？
git clone '復制的地址'
git checkout -b dev origin/dev
git checkout -b xiaofei dev
git status
git commit -a -m "task0002: 基礎布局功能"
git checkout dev
git pull
git merge xiaofei
git push
git checkout xiaofei
git merge dev
// 每個組員除了基於dev分支新建的本地分支命名不一樣之外，其他基本一樣。
2.3 此過程可能會遇到的問題
在執行 git pull 或者 git merge 操作的時候
2.3.1 如果出現這樣的代碼
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch。
# lines starting with "#" will be ignored, and an empty message aborts the commit
// 可以按 ESC 退出鍵，輸入 :wq 然后敲回車就可以恢復正常，然后繼續git push 即可
2.3.2 發現有沖突怎么辦？
// 如果提示有沖突，在你的編輯器里看到代碼是這樣的
>>>>>> HEAD
// 從HEAD到下面的====之間的代碼是你當前分支上的代碼
function a () {
console.log('a')
}
======
// 從======到下面的>>>>>之間的代碼是你要合並過來的代碼
function a () {
console.log('aa')
}
>>>>>> xiaofei
// 需要小狒和小智商量，保留小智的還是保留小狒的，還是兩個人的都要保留一部分。手動改好代碼后，執行
git add '沖突的文件名'
git commit -m '解決沖突'
git push
2.3.2 如何放棄本地修改？
// 當小智在他的本地xiaozhi分支上加功能時，可能他開始沒考慮全面，想把本地修改的內容都刪掉重新來過。
// 當小智還沒有 git add 緩存代碼時
git checkout -- '想放棄修改的文件名（帶路徑）'
// 或者放棄所有文件的修改
git checkout .
// 當小智已經把想撤銷修改的文件執行了 git add 的時候
git reset HEAD '想放棄修改的文件名（帶路徑）'
git checkout -- '想放棄修改的文件名（帶路徑）'
// 當小智已經把想撤銷修改的文件不僅git add還git commit的時候
git reset --hard HEAD^
// 可以用這條命令來恢復至上一次commit的狀態，如果發現已經提交了好幾次怎么辦，噗，沒忍住笑出了聲。如果直接回退肯定是可以的，但是這中間的幾次commit可能又有你想要的代碼，這個說實話，有點慘。說個比較實際的方案吧。把現在的代碼文件夾先復制一份。再執行
git log
// 看看你想回退到哪次commit的狀態，找到那次commit的版本號（記住關鍵的前幾位就可以了），然后
git reset --hard e235a
// 然后再從復制的那份文件夾中去對比，看看哪些是你想要的，想要的就加進來。
3. 測試階段的實際場景與常用命令
終於到了開發完成，要測試的時候了。此時，所有人各自對應的本地分支代碼(xiaozhi分支，xiaofei分支)都應該和dev保存一致了。
其實就可以把release分支當作dev分支，只不過開始是大家都推送到dev分支上做開發，而現在是都推送到release分支上改bug。
// 組長：
git checkout -b release dev
git push -u origin release
// 組員小智：
git checkout -b release origin/release
git checkout xiaozhi
git status
git add *
git commit -m "bug0001：修復首頁xxxx的問題"
git checkout release
git pull
git merge xiaozhi
git push
git checkout xiaozhi
git merge release
// 繼續解決下一個bug
// 組員小狒
git checkout -b release origin/release
git checkout xiaofei
git status
git add *
git commit -m "bug0002：修復列表頁的XXXX的問題"
git checkout release
git pull
git merge xiaofei
git push
git checkout xiaofei
git merge release
// 繼續解決下一個bug
// 當所有測試提出的bug都解決完后，大家應該保證dev分支，release分支，各自的本地分支(xiaozhi,xiaofei)都一樣
// 組長：
// 合並release分支到dev分支上
git checkout dev
git merge release
git push
// 合並release分支到master分支上並打上標簽版本號
git checkout master
git merge release
git push
git tag -a v1.0.0 -m '1.0.0版本'
git push origin --tags
// 組員們繼續寫功能開始進行下一版本的產品迭代，重復2.2.4-2.2.10步驟
4. 上線后客戶反饋有bug怎么辦？
有可能當組員們已經在各自的本地分支(xiaozhi, xiaofei)上去做下一版本的開發的時候，客戶反饋一些測試小姐姐們當時沒有測出來的bug。此時大家肯定不會直接去把dev分支再去合並到master分支了。
// 組長：
// 4.1.1 基於master分支新建一個hotfix001分支
git checkout -b hotfix001 master
// 4.1.2 與遠程hotfix001分支關聯起來
git push -u origin hotfix001
// 組長將這個重大而又緊急的任務指派給小智
// 組員小智：
// 4.1.3 檢出遠程分支hotfix001到本地分支hotfix001
git checkout -b hotfix001 origin/hotfix001
// 4.1.2 小智一頓牛逼操作之后
git commit -a -m "hotfix001: 解決線上xxxx的問題"
git push
// 4.1.3 測試通過后組長去拉取hotfix001的代碼並合並回master分支
git checkout hotfix001
git pull
git checkout master
git merge hotfix001
git push
git tag -a v1.0.1 -m '1.0.1版本：修復XXXX等一系列的問題'
git push origin --tags
// 4.1.4 接下來判斷這個線上的bug下一版本是否還要處理，如果這個功能還要的話，為了避免下一版本出現同樣的問題，那組長還需要把這個hotfix001分支合並到dev分支中去
git checkout dev
git pull
git merge hotfix001
git push
// 4.1.5 線上bug分支hotfix001完成了它光榮的使命，可以刪除了
git branch -d hotfix001
git push origin --delete hotfix001
5.后話：
我也在用git圖形化工具，比如sourcetree。相信很多人也在用，其實用命令行還是不如sourcetree那么方便而強大的。比如在撤銷修改的時候，sourceTree可以只撤銷這個文件你所改動的某一部分，而git命令行只能對某一個文件的所有改動撤銷修改（當然，可能是我對git命令行操作還不那么深入的緣故，但是我相信就算git命令行能做到，也遠沒有圖形化工具那么方便）。
不過我覺得我寫這篇文章其實還是有意義的，工作了這么久，幾乎天天都會用到git，一些常見git命令都不懂也說不過去，對自己要求並不那么高，並不是要強到什么都可以立刻想到用什么git命令去解決，而此篇文章中工作流常用到的命令還是要熟記於心的。
大家可以用自己的github賬號並且找一個小伙伴去建一個倉庫模擬體驗一下上述多人協作的過程，如果有問題可以一起交流下。
另外，你可能會感興趣的一些點：