Git入門（二）——團隊開發基本流程概述

前言

本文旨在幫助沒有接觸過Git的同窗，使用Git以及GitHub的基本功能，適用於初學者。

因爲內容比較多，一次寫不完，故作成連載，之後還會更新其它內容。

第一期：Git入門（一）——基本操做及理論
第二期：Git入門（二）——團隊開發基本流程概述 (本期)

步驟零：把項目跑起來

分爲如下兩種狀況：全新的項目，中途接手的項目

不管哪一種狀況，都應該先把GitHub倉庫clone到本地，有一個區別就是，全新的項目須要先在GitHub上新建倉庫。

//做用：把地址中的在線倉庫clone到本地的文件夾中
git clone <倉庫地址> <本地的文件夾>

請耐心等它跑完。
在本地擁有了代碼以後，就開始跑項目了。

若是是已有的舊項目，接下來就是檢查開發環境、數據庫、Nginx、redis等等，以確保項目能成功的跑起來。
若是是新項目，倉庫中只有一個readme.md，就不須要這一步（但須要額外的一步項目初始化，具體如何初始化，取決於開發使用的編程語言）。

步驟一：把本地倉庫調整到工做狀態

出於安全起見，一個嚴謹的團隊，必然會制定一些合做開發的規範，好比

• 不能向主分支直接提交代碼
• 不能由舊分支向新分支發起合併請求

所以，在領取一個任務時，咱們本地的倉庫可能剛剛完成上一個任務，所以須要進行切回主分支、同步遠程倉庫的代碼、創建新分支等等操做。

假設咱們領取了新任務，issue的編號是300，而咱們本地倉庫還處於上次的275分支上，而且剛剛提交完代碼：

這時候須要先切換回主分支：

// 切換到主分支
git checkout master

而後把遠程主分支同步到本地主分支：
(分支關係： origin/master -> master)

// 拉取遠程倉庫的代碼
git pull

執行上一步之後，咱們本地的代碼已經和遠程倉庫徹底一致了。
接下來爲新領取的任務建立一個分支：

// 建立新分支
git checkout -b <分支號>

// 示例：建立分支編號爲300的新分支
git checkout -b 300

到此爲止，咱們既更新了本地的代碼爲最新版本，又爲新領取的任務作好了準備，由於新的issue將在300分支上完成開發，所以，在合併代碼以前，不會對master分支產生影響。

接下來就開始寫代碼了。

步驟2、提交代碼

假設如今個人代碼已經寫完了，在徹底保存以後，終端中的分支號是黃色的，黃色表示代碼有改動，但還沒有提交。

咱們能夠查看代碼變動信息（這一步不是必須的）：

// 查看代碼狀態
git status

從返回的結果來看，有一個文件是modified狀態，這說明：
Git發現了一個文件出現更改，但並沒有記錄這個更改，所以提示信息是紅色的。

那麼咱們怎麼讓Git記錄這些更改呢？

// 記錄當前目前的全部文件變動
// 此命令應該在項目根目錄執行
git add .

再git status 就能夠看到剛剛顯示紅色的文件已經變成綠色：

接下來能夠提交代碼了（也至關於打一個保存點）：

// 在本地提交代碼變動，最後是備註信息
git commit -m <備註信息>
// 示例
git commit -m issue300已完成

提交完成後，本來黃色的分支號會從新變成綠色：

接下來就是把本地的代碼提交到遠程分支上：
(分支關係 300 -> origin/300)

// 把本地的分支推送到遠程倉庫
git push origin <分支號>

// 示例：把本地的300分支推送到遠程的300分支
git push origin 300

在提示信息中，能夠看到，但願用戶訪問GitHub來創建Pull Request。
至於GitHub的操做步驟，在第一期中已經講解，本文專一於講解Git命令。

附錄一 解決衝突

衝突產生緣由

只要有代碼合併就不可避免的產生衝突，衝突的產生，仍是要從分支提及。

剛剛咱們提到了一條規範：

• 不能向主分支直接提交代碼

基於這個規範，團隊的成員們須要分別在本身的分支上編寫，最終依次向主分支發起合併。

在提交代碼時，Git會以「行」爲單位，記錄每一行代碼的改動狀況，好比，在test分支，把某一行的123改爲了456，Git會記錄下:
123 -> 456
合併代碼時，Git會找到master分支上的123這一行，而且改爲456:
123 -> 456

咱們先看一種狀況：

若是A把123改爲了456，B更新了A修改以後的代碼，又把它改爲了789，

此時是不會有衝突的，由於B是把456改爲了789，而不是把123改爲了789。

但下面這種狀況就不同了：

A把123改爲了456，而且合併到主分支，但B沒有更新A的更改，而是直接把123改爲了789，那麼，再去合併B的分支時，就會顯示衝突

那麼Git到底該聽誰的？

所以就須要解決衝突了。
這也就是爲何有了第二個規範：

• 不能由舊分支向新分支發起合併請求

在合併代碼時，當前的改動必須基於最新的主分支

解決衝突

發生衝突時有兩種解決辦法，一是在線上修改，二是將衝突代碼拉下來，在本地修改。

若是衝突發生在本地，合併代碼時會提示conflicts，而且會提示具體哪一個文件發生衝突：

示例中是test.txt文件發生衝突，因此打開文件：

會出現一排<<<<<<<和一排>>>>>>>，中間夾住的，就是衝突的代碼。

圖中，當前的代碼是789，而300分支的成員想改爲456。
解決辦法：

• 將衝突的代碼刪掉一部分，使程序能夠正常運行（好比，在示例中，我打算刪掉789）
• 刪掉全部的箭頭、＝等等
• 未發生衝突的代碼不動
• 保存文件
• 從新執行git add .
• 從新執行git commit -m <備註信息>，把合併的結果提交

最終的效果以下：

代碼只剩一行「456」，終端中從新顯示綠色提示符。

附錄二 更新代碼

剛纔說到第二條規範：

• 不能由舊分支向新分支發起合併請求

好比，當你還在寫本身的issue時，其餘成員已經成功的向主分支貢獻了代碼。此時，主分支發生更新，而你的分支仍是基於舊的主分支，所以你須要把新的主分支拉取下來。

這個時候，若是直接用git pull，大機率會出問題。

因此須要用到下面的方案：

// 把遠程倉庫的全部變動同步到本地的origin鏡像中
git fetch --all

此時未進行代碼合併，因此本地的代碼沒有變化。

// 把主分支合併到當前工做的分支
git merge origin/master

此時，你當前的工做分支再也不基於舊的主分支，因爲合併，已經基於新的主分支了。
在合併過程當中也可能出現衝突，按照附錄一的方法解決便可。

附錄三 重置代碼

若是你的代碼出現了嚴重錯誤，想放棄所有更改，重置爲最新版本的主分支代碼，能夠在當前的工做分支上執行：

// 拉取遠程倉庫的全部更改
git fetch --all
// 把當前工做分支的代碼，用最新的master分支徹底替換
git reset origin/master

而後，本地的工做分支，就和遠程倉庫的主分支如出一轍了，從新編寫代碼便可。

總結 一圖勝千言

團隊合做開發的泳道圖大概是這樣的：

成員在領取任務時，是一塊兒進行的，誰也不知道哪一個成員先提交代碼。就像異步請求同樣，誰也不知道哪一個請求先返回。

所以，要想順利的完成合做，有兩個關鍵：

• 一是具有解決衝突的能力，
• 二是及時的拉取遠程倉庫的代碼變動。

版權聲明

本文做者： 河北工業大學夢雲智開發團隊 - 劉宇軒