本文主題是如何向工具初學(xué)者介紹分布式版本控制系統(tǒng) Git。除了了解關(guān)于 Git 的基本知識(shí)以外，大家還可以學(xué)到一些工具學(xué)習(xí)方面的東西。

我發(fā)現(xiàn)的問題

我的一些職業(yè)經(jīng)歷涉及跨職能領(lǐng)域，因此我了解所有同事的工作方式。我記得有一家公司在我加入的幾周前才開始使用 Git。

我用三步把 post-it 放到屏幕上：第一步是 add，第二步是 commit，第三步是 push。

他們不知道為什么要用這三步，他們只知道為了防止發(fā)生其他問題，他們應(yīng)該遵循這三個(gè)步驟。但是問題還是頻頻發(fā)生，所以我決定準(zhǔn)備一個(gè)關(guān)于 Git 的討論會(huì)。

想法

我喜歡在頭腦中繪圖。我不寫「思維導(dǎo)圖」，因?yàn)樗鼈兪潜娝苤膱D像形式。而我所說的「圖」是一種大腦中的有框架、結(jié)構(gòu)化或其他形式的圖像表征。例如，我在頭腦中想象骰子來學(xué)習(xí)加法。

所以我準(zhǔn)備了一些圖。理解這篇文章不一定需要看懂這些圖。但出于可訪問性，我對(duì)每一張圖都作出了解釋。

在這種情況下，詞匯的教學(xué)就非常重要了。否則他們無法理解來自 Git 的信息。這些圖是一種很好地向他們介紹詞匯的方式。

分布式版本控制系統(tǒng)

概括圖包括四部分，分別是：

開發(fā)環(huán)境中的：

工作區(qū)

暫存區(qū)或索引

本地版本庫

服務(wù)器中的：

遠(yuǎn)程版本庫

到那個(gè)時(shí)候，你就可以解釋分布式版本控制系統(tǒng)的好處了。

復(fù)制版本庫

在復(fù)制版本庫時(shí)，遠(yuǎn)程版本庫中的數(shù)據(jù)要傳遞到兩個(gè)區(qū)域：

工作區(qū)

本地版本庫

在工作區(qū)中進(jìn)行更改

工作區(qū)中有兩類文件：

追蹤文件：Git 知道的文件。

未追蹤文件：因?yàn)樯形刺砑右虼?Git 不知道的文件。

更新遠(yuǎn)程版本庫

當(dāng)工作區(qū)更改就緒時(shí)，必須先把它們添加到暫存區(qū)中。

當(dāng)暫存區(qū)中有一組特定的更改時(shí)，我們就需要在本地庫中創(chuàng)建帶有這些特定信息的 commit。

當(dāng)本地版本庫中有一或多個(gè)準(zhǔn)備和世界其他地方共享的 commit 時(shí)，我們必須把它們 push 到遠(yuǎn)程版本庫中。

這時(shí)，開發(fā)環(huán)境中的文件狀態(tài)已經(jīng)有所不同了：已修改、已暫存和已提交（modified, staged and committed）。

此外，你還可以解釋：

如何顯示工作區(qū)的文件更改：git diff

如何顯示暫存區(qū)的文件更改：git diff –staged

在將文件添加到暫存區(qū)后，如何在工作區(qū)中更改文件

等等

更新開發(fā)環(huán)境

抓取（fetch）

執(zhí)行 git fetch 后，遠(yuǎn)程庫中的數(shù)據(jù)將僅傳遞到本地庫中。

Pulling

當(dāng)執(zhí)行 git pull 后，遠(yuǎn)程庫中的數(shù)據(jù)會(huì)傳輸?shù)絻蓚€(gè)區(qū)域：

本地庫：抓取（fetch）

工作區(qū)：合并（merge）

你可以用 git pull—rebase 查看 commit 歷史。它是由 fetch + rebase 而不是 fetch + merge 組成的。它將會(huì)重新執(zhí)行你的本地提交，而且你無法看到提交歷史中已知的 diamond shape。

下一步

你可以在開發(fā)環(huán)境中添加另一個(gè)區(qū)域來解釋暫存區(qū)：dirty work directory。

如果人們將這些概念內(nèi)化，他們就可以建立堅(jiān)實(shí)的基礎(chǔ)，從而更容易地使用分支、提交歷史以及衍合（rebasing）等。

溫馨提示

我也曾用過其他版本控制系統(tǒng)（Visual SourceSafe、TFS 和 Subversion），以我的個(gè)人經(jīng)驗(yàn)來講，缺乏知識(shí)對(duì)于使用舊工具和新工具而言都有害。我們不僅僅要選擇工具，還要掌握工具。