Git 是什么？

Git 是一個分布式的代碼管理容器，本地和遠(yuǎn)端都保有一份相同的代碼。 Git 倉庫主要是由是三部分組成：本地代碼，緩存區(qū)，提交歷史，這幾乎是所有操作的本質(zhì)，但是為了文章更加簡單易懂，就不圍繞這塊展開了，有興趣的可以去了解下。 開門見山，我們直接來說說 Git 有哪些常見的操作。

Git 有哪些常規(guī)操作？

我們簡單說說Git有哪些常規(guī)操作，能夠讓我們應(yīng)付簡單的開發(fā)需求。

克隆代碼

✦ 克隆遠(yuǎn)端代碼

git clone http://git.code.oa.com/QCFE/sqlserver.git

✦ 查看本地的代碼狀態(tài)

// 可以明確的呈現(xiàn)出本地倉庫的狀態(tài)
// 哪些文件發(fā)生改動，哪些文件已經(jīng)提交到本機
// 以及一些操作指示。
git status

✦ 同步遠(yuǎn)端分支變化

// 拉取指定分支的變化
git fetch origin master
// 拉取所有分支的變化
git fetch
// 拉取所有分支的變化，并且將遠(yuǎn)端不存在的分支同步移除【推薦】
git fetch -p

✦ 同步遠(yuǎn)端代碼變化。

// 都是先 git fetch，然后執(zhí)行合并操作
// 不同的是，git pull 執(zhí)行的是 git merge，git pull -r 執(zhí)行的是git rebase
git pull origin master
git pull -r origin master

關(guān)于 git merge 和 git rebase 各自的優(yōu)劣，后文會詳細(xì)介紹。

這部分主要介紹了關(guān)于代碼克隆，同步遠(yuǎn)端代碼變化的相關(guān)操作。接下來，我們看看關(guān)于本地代碼的一些操作。

操作 commit

首先我們要明確一個概念：就是每個 commit 都是一份完整的代碼狀態(tài)，用一個 commitID 來唯一標(biāo)志。

從某個角度上來說，Git維護的就是一個commitID樹，分別保存著不同狀態(tài)下的代碼。 所以你對代碼的任何修改，最終都會反映到 commit 上面去。

✦ 新增 commit

// 添加文件到緩存區(qū)，然后提交到本地倉庫
git add files
git commit -m '提交備注'

✦ 撤銷 commit

// 會將提交記錄回滾，代碼不回滾
git reset b14bb52
// 會將提交記錄和代碼全部回滾
git reset --hard b14bb52
// 將部分代碼文件回滾
git checkout -- files

✦ 合并 commit 合并 commit，本質(zhì)上合并兩份不同狀態(tài)下的代碼。

// Git 提供了兩種合并 commit 的方式
git merge master
git rebase master

那么 git rebase 和 git merge 到底有什么區(qū)別呢？ merge是兩個分支處理沖突后，新增一個 commit 追加到master上。 rebase是將someFeature分支上的commit記錄追加到主分支上，值得注意的是，這個時候他的commit其實已經(jīng)發(fā)生變化。

相對來說，git merge 處理沖突更直接，而git rebase 能夠保證清晰的 commit 記錄。 合并 commit 的時候，通常會發(fā)生沖突。 可以全局搜索特殊字符比如，找到需要處理的代碼位置，然后認(rèn)真分析應(yīng)該保留哪一部分代碼。

在團隊協(xié)作的時候，分支是必不可少的。那么應(yīng)該如何對分支進行操作呢？

操作分支

所謂的分支其實就是一個指向 commitID 的指針，你可以去 .git/refs/heads 里去看看。

通常情況下，我們建議分支至少能夠明確的標(biāo)記功能名稱，如果能標(biāo)記用戶就更好了，比如 qixiu/feature 。 ✦ 查看分支

可以同時看到本地分支和遠(yuǎn)端分支，配合上前文介紹的 git fetch -p 可以第一時間查看到最新的分支信息。 ✦ 新增本地分支 其實就是創(chuàng)建一個指針指向某一個 commitID。

// git branch qixiu/feature + git checkout qixiu/feature
// 從當(dāng)前分支新增一個新的分支qixiu/feature
// 一般情況下，我們應(yīng)該從master或者其他穩(wěn)定分支來新增分支
git checkout -b qixiu/feature // 新建分支
git checkout qixiu/feature // 切換分支

✦ 刪除本地分支 其實就是移除一個指向 commitID 的指針。

// 刪除本地分支，如果本地還有未合并的代碼，則不能刪除
git branch -d qixiu/feature
// 強制刪除本地分支
git branch -D qixiu/feature

✦ 新增遠(yuǎn)端分支 通常情況下，我們是新建本地分支，然后更新到遠(yuǎn)端的方式來新增一個遠(yuǎn)端分支

git push origin qixiu/feature

✦ 刪除遠(yuǎn)端分支 同樣，我們也是通過更新到遠(yuǎn)端的方式來刪除一個遠(yuǎn)端分支

// 等同于git push origin -d qixiu/feaure
git push origin :qixiu/feature

簡單匯總一下

上面說的可能有些分散，這兒簡單總結(jié)一下有哪些經(jīng)常使用的操作：

git status // 查看本地代碼狀態(tài)
git add files // 添加代碼到緩存區(qū)
git commit -m '提交內(nèi)容的備注' // 提交代碼到本地倉庫
git checkout -b branchName // 不加-b就是普通切換分支
git fetch -p // 同步遠(yuǎn)端分支狀態(tài)
git pull -r origin branchName // fetch遠(yuǎn)端代碼到本地，并且以rebase的方式合并代碼
git push origin branchName // 更新本地代碼到遠(yuǎn)端

以上幾條命令已經(jīng)能夠應(yīng)付日常的操作，稍微復(fù)雜一些的場景后文會介紹

基于基本操作，在實際項目中，我們應(yīng)該怎么利用 Git 實現(xiàn)協(xié)作呢？

Git 有哪些比較好的實踐？

Git 有一些成熟的開發(fā)流程，比較主流的有兩種：基于功能分支的開發(fā)流程 和 GitFlow開發(fā)流程。 相對來時，我更推薦前者，如果是復(fù)雜的大型項目，推薦GitFlow開發(fā)流程。 接下來，簡單介紹下這兩種協(xié)作模式。

基于功能分支的協(xié)作模式

基于功能分支的開發(fā)流程其實就是一句話：用分支來承載功能開發(fā)，開發(fā)結(jié)束之后就合并到 master 分支。 他的優(yōu)點是能夠保證master分支的整潔，同時還能讓分支代碼邏輯集中，也便于 CodeReview。

分支命名規(guī)范

推薦使用如下格式：ownerName/featureName。 這樣既便于知道分支覆蓋的功能，也便于找到分支的負(fù)責(zé)人。以后清理分支的時候也很方便。

開發(fā)流程

✦ 從 master 切出一個新分支

git checkout -b qixiu/newFeature

✦ 開發(fā)一些新功能，然后提交 建議較多頻次的提交代碼到本地倉庫，以便能夠更靈活的保存或撤銷修改。 此外為了保證提交日志的清晰，建議備注清楚的注釋。

git status
git add files // 挑選需要提交的文件，或者全部提交
git commit -m '提交備注'
git push origin qixiu/newFeature

✦ 如果功能開發(fā)完成，可以發(fā)起一個CodeReview流程 ✦ 如果代碼測試通過，合并到 master，然后準(zhǔn)備上線

// 冗余版 合并到 master
git checkout master
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // 處理沖突
git checkout master
git merge qixiu/newFeature
git push origin master
// 精簡版 合并到 master
git checkout qixiu/newFeature
git pull -r origin master // 將master的代碼更新下來，并且rebase處理沖突
git push origin master // 將本地代碼更新到遠(yuǎn)端

有幾點需要注意： 不要在master合并代碼，保證master的可用性很重要。 確保在正確的分支執(zhí)行正確的操作。 無論是處理沖突還是更新遠(yuǎn)端代碼，請保有敬畏之心。

到此，一個正常的基于功能分支的開發(fā)流程就完成了。接下來看看另外一個開發(fā)流程。

GitFlow 開發(fā)流程

GitFlow 比前文講的基于功能分支的開發(fā)流程要復(fù)雜得多，它更適合大型的復(fù)雜項目。 它圍繞項目發(fā)布流程定義了一個嚴(yán)格的分支模型，所有的開發(fā)流程都是圍繞這個嚴(yán)格的分支模型進行。 而這個模型約定了每個分支的角色，以及他們?nèi)绾螠贤ā?/p>

我們先來看看 GitFlow 開發(fā)流程中幾個約定的分支，以及他們各自承擔(dān)的角色是怎么樣的？

✦ Master分支：用于存放線上版本代碼，可以方便的給代碼打版本號。 ✦ Develop分支：用于整合 Feature 分支。 ✦ Feature分支：某個功能的分支，從 Develop 分支切出，并且功能完成時又合并回 Develop 分支，不直接和 Master 分支交互。 ✦ Release分支：通常對應(yīng)一個迭代。將一個版本的功能全部合并到 Develop 分支之后，從 Develop 切出一個 Release 分支。這個分支不在追加新需求，可以完成 bug 修復(fù)、完善文檔等工作。務(wù)必記住，代碼發(fā)布后，需要將其合并到 Master 分支，同時也要合并到 Develop 分支。 ✦ Hotfix分支：緊急修復(fù)的分支，是唯一可以從 Master 切出的分支，一旦修復(fù)了可以合并到 Master 分支和 Develop 分支。

從每個分支的功能和約定可以看出，它流程多約束多，對于小規(guī)模應(yīng)用并不適合。 當(dāng)然 GitFlow 有一些輔助工具 gitflow 可以自動化的完成這些任務(wù)，對于大型項目也很有幫助。

前面講了 Git 有哪些基本操作，然后介紹了兩個主流的工作流程。 接下來我們看看 Git 有哪些特別的技巧值得一提。

Git 有哪些小技巧？

Git 操作除了基本的代碼管理功能，還有一些小技巧能夠讓你眼前一亮。

git reflog，查看操作記錄

這個我一定要放在第一個介紹，因為它曾經(jīng)數(shù)次解救了我的代碼

仔細(xì)看上圖，reflog 記錄了你所有的 git 命令操作，對于復(fù)原某些莫名其妙的場景或者回滾誤操作有極大的幫助。 試想一個場景：你使用 git reset --hard commitID 把本地開發(fā)代碼回滾到了一個之前的版本，而且還沒有推到遠(yuǎn)端，怎么才能找回丟失的代碼呢？ 你如果使用 git log 查看提交日志，并不能找回丟棄的那些 commitID。 而 git reflog 卻詳細(xì)的記錄了你每個操作的 commitID，可以輕易的讓你復(fù)原當(dāng)時的操作并且找回丟失的代碼。 當(dāng)然，如果你丟失的代碼都沒有提交記錄，那么恭喜你，你的代碼真的丟了。

壓縮提交記錄

這也是一個很實用的功能，前文提過，我們在開發(fā)中的時候盡量保持一個較高頻率的代碼提交，這樣可以避免不小心代碼丟失。但是真正合并代碼的時候，我們并不希望有太多冗余的提交記錄，而且 rebase 合并代碼的時候，會把每個 commit 都處理一下，有時候會造成冗余的工作。 所以，壓縮日志之后不經(jīng)能讓 commit 記錄非常整潔，同時也便于使用 rebase 合并代碼。

那么，如何壓縮commit記錄呢？ ✦ 使用 git log 找到起始 commitID ✦ git reset commitID ，切記不要用 --hard 參數(shù) ✦ 重新 git add git commit ✦ git push -f origin branchName ，因為會有沖突，所以需要強制覆蓋遠(yuǎn)端分支，請務(wù)必謹(jǐn)慎。 ✦ 合并到 master 中，然后更新遠(yuǎn)端 master。

此外還有兩種壓縮日志的辦法： git commit --amend ：追加 commit 到上一個 commit 上。 git rebase -i ：通過交互式的 rebase，提供對分支 commit 的控制，從而可以清理混亂的歷史。

從實際應(yīng)用來說，三種日志壓縮都很優(yōu)秀， git reset 更簡單， git rebase -i 更細(xì)膩。

git rebase，合并代碼

前文簡單介紹了 git rebase 和 git merge 的區(qū)別，坦率講，他們各有優(yōu)劣。 git rebase 能讓你的 commit 記錄非常整潔，無論是線上回滾還是 CodeReview 都更輕松；但卻是一個有隱患的操作，使用時務(wù)必謹(jǐn)慎。 git merge 操作更安全，同時也更簡單；但卻會增加一些冗余的 commit 記錄。

這兒簡單說說 rebase 的合并流程和注意事項吧。看下圖

有三個點需要注意： ✦ rebase 先找出共同的祖先節(jié)點 ✦ 從祖先節(jié)點把 pay 分支的提交記錄摘下來，然后 rebase 到 master 分支 ✦ rebase 之后的 commitID 其實已經(jīng)發(fā)生了變化 尤其是第三點，經(jīng)常會讓人誤操作，所以務(wù)必注意。

試想一下，開發(fā)過程中，如果我們頻繁的 rebase master 分支，會有什么后果呢？

當(dāng)你不斷 rebase master 的時候，其實你本地的 d 都變成了 d' ，再要和遠(yuǎn)端 pay 分支保持一致，你的本地分支 commit 記錄已經(jīng)不堪入目了。

另外要注意，絕不要在公共的分支上使用 rebase！！！

所以，為了安全，團隊可以考慮采用 merge。

pull request，方便CodeReview

Git 不僅提供了代碼托管以及代碼開發(fā)的幫助，還提供了代碼審核類似的功能。 當(dāng)我們在功能分支開發(fā)完成之后，可以發(fā)起一個 pull request 請求，選擇需要對比的兩個分支

它會創(chuàng)建一個 pull request，制定相關(guān)人員來對代碼進行 review。 通常情況下，團隊?wèi)?yīng)該鼓勵交叉 review，涉及到公共代碼的時候，一定要讓相關(guān)人 review。

git hook，Git 的生命周期

這個大多數(shù)人應(yīng)該都，聽說過，git操作有它自身的生命周期，在不同的生命周期，我們可以做一些自動化的事情。

舉兩個簡單的例子： ✦ pre-commit的時候我們可以做 eslint ✦ post-commit的時候，我們可以做利用 jenkins 類似的工具做持續(xù)集成

當(dāng)然還有更多的聲明周期，具體可以參考 Git 鉤子

git submodule git subtree，管理第三方模塊

這兩個命令通常用來管理公用的第三方模塊。比如一些通用的底層邏輯、中間件、還有一些可能會頻繁變化的通用業(yè)務(wù)組件。 當(dāng)然，兩者還是有區(qū)別的。 git submodule 主要用來管理一些單向更新的公共模塊或底層邏輯。 git subtree 對于部分需要雙向更新的可復(fù)用邏輯來說，特別適合管理。比如一些需要復(fù)用的業(yè)務(wù)組件代碼。在我之前的實踐中，我也曾用subtree來管理構(gòu)建系統(tǒng)邏輯。

git alias，簡化 Git 命令

我們可以通過配置 git alias 來簡化需要輸入的 Git 命令。 比如前文的 git subtree 需要輸入很長的 Git 命令，我們可以配置 .git/config 文件來解決。

// git stpull appfe demo/xxx
// git stpush appfe demo/xxx
[alias]
stpull = !git subtree pull --prefix=$1 appfe $2 \
 :
stpush = !git subtree pull --prefix=$1 appfe $2 \
 git subtree split --rejoin --prefix=$1 $2 \
 git subtree push --prefix=$1 appfe $2 \
 :

總結(jié)說點啥？

該文首先介紹了 Git 常規(guī)操作 ✦ 包括克隆代碼、操作 commit、操作分支等。其實 Git 常規(guī)操作的命令并不多，請看第一部分的簡單總結(jié)。

其次介紹了 Git 開發(fā)流程 ✦ 該部分主要介紹了兩種主流的開發(fā)模式：比較輕量的 基于功能分支的開發(fā)流程 *和適合復(fù)雜項目的 *GitFlow 開發(fā)流程 ，兩種模式各有使用的場景，對于常規(guī)使用，前者就已經(jīng)足夠了。

最后介紹了一些 Git 實用技巧 ✦ 主要包括：reflog 操作，壓縮日志，rebase 的注意事項，利用 pull request 做 codeReview，利用 git hook 做一些自動化工作等。

題圖：pexels，CC0 授權(quán)。