萌新(我)的Git備忘錄

又是喜聞樂見的背景時間--最近也開始接觸面試了，發現不少童鞋對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相關的教程~在此不會過多的涉獵。