又是喜聞樂見的背景時間--最近也開始接觸面試了，發現很多童鞋對git十分陌生，甚至聽到git有點恐慌，不過這樣無可厚非，畢竟如果是自己單幹的話確實可能接觸不到協作層面的情境。
對的，比如說我
本文只適合我等萌新，大佬可能就不需要繼續看下去啦，如果是幫忙糾正錯誤的話就十分歡迎~
本文會涉及到的內容--
- 剛進入新的工作群該用git幹啥
- 開始
接客接活之後改用git幹啥 - 一起
接客接活時該怎麼保證安全(?) - 小結
寫在前頭
還是和我之前的風格一樣，這裡只可能出現業務型的乾貨，並不會在此過多的原理陳述(一是怕誤人子弟，二是感覺沒必要)，git作為一種工具，我們能在工作中用得順手即可。
注意：本文的開發機器為Mac，程式碼倉庫為Gitlab
剛進入新的工作群該用git幹啥
進入新公司或是加入新的工作群，最重要的事情當然是要拿到當前業務的程式碼，這是進行後續開發工作的基礎。就我們當前的開發情況來說，我們需要做以下幾件事--
①註冊賬號，與管理倉庫的同事溝通，開通相關專案的許可權
一般在這個時候，都會要求大家提供一串祕鑰--本機的SSH Key，如果之前有在本機生成過SSH Key的話我們可以在終端輸入（如果沒有的話建議使用搜尋引擎查詢生成SSH Key的相關教程）
cat ~/.ssh/id_rsa.pub
複製程式碼這樣終端便會顯示一串祕鑰，之後只需把祕鑰告知同事即可，為什麼要做這件事呢？因為就算我們有檢視專案的許可權，我們的機器也沒有將其克隆下來的許可權，只有將我們的SSH Key記錄到gitlab中，我們才可以克隆專案。
②克隆程式碼
進入相應的目錄
cd my_project
在本目錄下將遠端程式碼克隆到本地
git clone ssh://xxx/xx/xx.git
複製程式碼開始接客接活之後改用git幹啥
①建立自己的開發分支
正常情況下，我們是不會在master分支下進行開發的，這既不安全也不優雅(一般也不會允許非管理員在master分支提交程式碼)。所以我們就需要建立一個屬於自己的開發分支，它與master的程式碼時刻保持同步，提交程式碼時merge到master分支即可。
git branch
//確認在master分支
git checkout -b xxx(自定義分支名)
//從所在分支，checkout出一個新的分支，這個新分支擁有所在分支的所有程式碼
git push -u origin xxx
// 將本地分支推往遠端倉庫
複製程式碼輸入這三行之後，我們就擁有了屬於自己的分支，因為這個分支是從master切出來的，所以它的程式碼與master完全一致，之後我們在此分支開發即可。
②管理自己的原始碼
在IDE裡面愉悅的搬磚一段時間之後，要記得勞逸結合！我們最好要養成定時提交程式碼的習慣，最好不要碼了一整天之後才想起來要提交程式碼，就我個人而言，在完成需求中的某個小需求時我便會提交或推送一次程式碼。
git add . or git add /xxx/...
//將本次改動全部加入快取區
git commit -m "" or git commit
//將程式碼提交到原生程式碼庫，並附帶相關注釋
複製程式碼③時刻同步master分支
維持一個專案的穩定性，其中一個要素就是保證程式碼的純淨，所以我們需要保證我們的開發分支需要時刻與master保持同步，我們團隊採用的rebase的方案。
git fetch origin
// 發現遠端倉庫最新的程式碼
git rebase origin/master
//同步遠端倉庫master分支
git push
//將你的程式碼推到遠端倉庫
or
git push -f origin xxx
//如果無法push則可以選擇下面這個方式**(前提是要確保本地的程式碼是絕對的完整)**
複製程式碼在這裡我們需要注意的是要記得fetch遠端的最新程式碼，然後才進行rebase。緊接著就是rebase時對衝突的應對--
git fetch origin
// 發現遠端倉庫最新的程式碼
git rebase origin/master
//同步遠端倉庫master分支
----conflict----
//rebase時發生衝突
git status
//定位衝突檔案
//...處理衝突...
git add .
//提交衝突處理到快取區，一定不能commit
git rebase --continue
//繼續rebase
or
//如果無法處理衝突則退出rebase復原始碼
git rebase --abort
複製程式碼④提交自己的第一個PR
為了保證程式碼的純淨，最理想的方式是隻有一個有許可權的管理員進行分支與master之間的合併，這裡用到的就是我們常說的PR(Pull Request)，簡單來說，就是向專案管理員提出一個merge的請求，管理員同意之後則會將我們的程式碼合併到master。
git fetch origin
git rebase origin/master
git push //...ok
複製程式碼將本地改動推送到遠端程式碼庫後，我們需要進入gitlab相應的專案，建立PR(圖中Merge Request選項，也就是Github中的Pull Request)
確認相關改動無誤後我們可以建立PR等待管理員review，建立好之後又有改動怎麼辦？沒關係的，我們只需要按照老方法將程式碼推送到伺服器，PR內容會自動更新至最新。
一起接客接活時該怎麼保證安全
背景--有一個比較大的需求，需要兩個人共同開發，並且需要這個需求最終共同上線。
對於我來說，這種情況不太常見，但是也想過相關的方案，在這裡之前的rebase方案就不太夠用了，需要區分主從分支。假設進行開發的童鞋為A和B--
// A童鞋
// on master
git checkout -b A
git push -u origin A
// B童鞋
git fetch origin
git checkout A
git checkout -b B
git push -u origin B
// 開發中...
// A童鞋
git add .
git commit
git fetch origin
git rebase origin/master
git push
// B童鞋
git add .
git commit
git fetch origin
git rebase origin/A
git push
複製程式碼這樣開發可以使得AB兩位的程式碼都能時刻與master分支保持同步，並且B還可以獲得A最新的開發程式碼，在共同開發某樣功能的時候應該會十分有用。最後B提交一個PR即可把兩人的程式碼合併，再由A發起合併到master的PR即可。
小結
其實這就是我個人開發時候的備忘錄，一些基本開發流程還是有的，如果有特殊需求的話，可以上網找找Git相關的教程~在此不會過多的涉獵。
