git 是什么？

git 是一個(gè)分布式的代碼管理容器，本地和遠(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)提交到本機(jī)

// 以及一些操作指示。

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

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

從某個(gè)角度上來說，git維護(hù)的就是一個(gè)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是兩個(gè)分支處理沖突后，新增一個(gè) commit 追加到master上。 rebase是將somefeature分支上的commit記錄追加到主分支上，值得注意的是，這個(gè)時(shí)候他的commit其實(shí)已經(jīng)發(fā)生變化。

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

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

操作分支

所謂的分支其實(shí)就是一個(gè)指向 commitid 的指針，你可以去 .git/refs/heads 里去看看。

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

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

// git branch qixiu/feature + git checkout qixiu/feature

// 從當(dāng)前分支新增一個(gè)新的分支qixiu/feature

// 一般情況下，我們應(yīng)該從master或者其他穩(wěn)定分支來新增分支

git checkout -b qixiu/feature // 新建分支

git checkout qixiu/feature // 切換分支

? 刪除本地分支 其實(shí)就是移除一個(gè)指向 commitid 的指針。

// 刪除本地分支，如果本地還有未合并的代碼，則不能刪除

git branch -d qixiu/feature

// 強(qiáng)制刪除本地分支

git branch -d qixiu/feature

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

git push origin qixiu/feature

? 刪除遠(yuǎn)端分支 同樣，我們也是通過更新到遠(yuǎn)端的方式來刪除一個(gè)遠(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ù)雜一些的場景后文會介紹

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

git 有哪些比較好的實(shí)踐？

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

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

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

分支命名規(guī)范

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

開發(fā)流程

? 從 master 切出一個(gè)新分支

git checkout -b qixiu/newfeature

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

git status

git add files // 挑選需要提交的文件，或者全部提交

git commit -m '提交備注'

git push origin qixiu/newfeature

? 如果功能開發(fā)完成，可以發(fā)起一個(gè)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)端

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

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

gitflow 開發(fā)流程

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

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

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

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

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

git 有哪些小技巧？

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

git reflog，查看操作記錄

這個(gè)我一定要放在第一個(gè)介紹，因?yàn)樗?jīng)數(shù)次解救了我的代碼

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

壓縮提交記錄

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

那么，如何壓縮commit記錄呢？ ? 使用 git log 找到起始 commitid ? git reset commitid ，切記不要用 --hard 參數(shù) ? 重新 git add && git commit ? git push -f origin branchname ，因?yàn)闀袥_突，所以需要強(qiáng)制覆蓋遠(yuǎn)端分支，請務(wù)必謹(jǐn)慎。 ? 合并到 master 中，然后更新遠(yuǎn)端 master。

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

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

git rebase，合并代碼

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

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

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

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

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

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

所以，為了安全，團(tuán)隊(duì)可以考慮采用 merge。

pull request，方便codereview

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

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

git hook，git 的生命周期

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

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

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

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

這兩個(gè)命令通常用來管理公用的第三方模塊。比如一些通用的底層邏輯、中間件、還有一些可能會頻繁變化的通用業(yè)務(wù)組件。 當(dāng)然，兩者還是有區(qū)別的。 git submodule 主要用來管理一些單向更新的公共模塊或底層邏輯。 git subtree 對于部分需要雙向更新的可復(fù)用邏輯來說，特別適合管理。比如一些需要復(fù)用的業(yè)務(wù)組件代碼。在我之前的實(shí)踐中，我也曾用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é)說點(diǎn)啥？

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

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

最后介紹了一些 git 實(shí)用技巧 ? 主要包括：reflog 操作，壓縮日志，rebase 的注意事項(xiàng)，利用 pull request 做 codereview，利用 git hook 做一些自動化工作等。

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

原文鏈接：https://cloud.tencent.com/community/article/527818