歡迎閱讀本系列關(guān)于如何使用 Git 版本控制系統(tǒng)的教程!通過本文的介紹，你將會了解到 Git 的用途及誰該使用 Git。

如果你剛步入開源的世界，你很有可能會遇到一些在 Git 上托管代碼或者發(fā)布使用版本的開源軟件。事實(shí)上，不管你知道與否，你都在使用基于 Git 進(jìn)行版本管理的軟件：Linux 內(nèi)核(就算你沒有在手機(jī)或者電腦上使用 Linux，你正在訪問的網(wǎng)站也是運(yùn)行在 Linux 系統(tǒng)上的)，F(xiàn)irefox、Chrome 等其他很多項(xiàng)目都通過 Git 代碼庫和世界各地開發(fā)者共享他們的代碼。

換個(gè)角度來說，你是否僅僅通過 Git 就可以和其他人共享你的代碼?你是否可以在家里或者企業(yè)里私有化的使用 Git?你必須要通過一個(gè) GitHub 賬號來使用 Git 嗎?為什么要使用 Git 呢?Git 的優(yōu)勢又是什么?Git 是我唯一的選擇嗎?這對 Git 所有的疑問都會把我們搞的一腦漿糊。

因此，忘記你以前所知的 Git，讓我們重新走進(jìn) Git 世界的大門。

什么是版本控制系統(tǒng)?

Git 首先是一個(gè)版本控制系統(tǒng)?，F(xiàn)在市面上有很多不同的版本控制系統(tǒng)：CVS、SVN、Mercurial、Fossil 當(dāng)然還有 Git。

很多像 GitHub 和 GitLab 這樣的服務(wù)是以 Git 為基礎(chǔ)的，但是你也可以只使用 Git 而無需使用其他額外的服務(wù)。這意味著你可以以私有或者公有的方式來使用 Git。

如果你曾經(jīng)和其他人有過任何電子文件方面的合作，你就會知道傳統(tǒng)版本管理的工作流程。開始是很簡單的：你有一個(gè)原始的版本，你把這個(gè)版本發(fā)送給你的同事，他們在接收到的版本上做了些修改，現(xiàn)在你們有兩個(gè)版本了，然后他們把他們手上修改過的版本發(fā)回來給你。你把他們的修改合并到你手上的版本中，現(xiàn)在兩個(gè)版本又合并成一個(gè)最新的版本了。

然后，你修改了你手上最新的版本，同時(shí)，你的同事也修改了他們手上合并前的版本。現(xiàn)在你們有 3 個(gè)不同的版本了，分別是合并后最新的版本，你修改后的版本，你同事手上繼續(xù)修改過的版本。至此，你們的版本管理工作開始變得越來越混亂了。

正如 Jason van Gumster 在他的文章中指出 即使是藝術(shù)家也需要版本控制，而且已經(jīng)在個(gè)別人那里發(fā)現(xiàn)了這種趨勢變化。無論是藝術(shù)家還是科學(xué)家，開發(fā)一個(gè)某種實(shí)驗(yàn)版本是并不鮮見的;在你的項(xiàng)目中，可能有某個(gè)版本大獲成功，把項(xiàng)目推向一個(gè)新的高度，也可能有某個(gè)版本慘遭失敗。因此，最終你不可避免的會創(chuàng)建出一堆名為project_justTesting.kdenlive、project_betterVersion.kdenlive、project_best_FINAL.kdenlive、project_FINAL-alternateVersion.kdenlive 等類似名稱的文件。

不管你是修改一個(gè) for 循環(huán)，還是一些簡單的文本編輯，一個(gè)好的版本控制系統(tǒng)都會讓我們的生活更加的輕松。

Git 快照

Git 可以為項(xiàng)目創(chuàng)建快照，并且存儲這些快照為唯一的版本。

如果你將項(xiàng)目帶領(lǐng)到了一個(gè)錯(cuò)誤的方向上，你可以回退到上一個(gè)正確的版本，并且開始嘗試另一個(gè)可行的方向。

如果你是和別人合作開發(fā)，當(dāng)有人向你發(fā)送他們的修改時(shí)，你可以將這些修改合并到你的工作分支中，然后你的同事就可以獲取到合并后的最新版本，并在此基礎(chǔ)上繼續(xù)工作。

Git 并不是魔法，因此沖突還是會發(fā)生的(“你修改了某文件的最后一行，但是我把這行整行都刪除了;我們怎樣處理這些沖突呢?”)，但是總體而言，Git 會為你保留了所有更改的歷史版本，甚至允許并行版本。這為你保留了以任何方式處理沖突的能力。

分布式 Git

在不同的機(jī)器上為同一個(gè)項(xiàng)目工作是一件復(fù)雜的事情。因?yàn)樵谀汩_始工作時(shí)，你想要獲得項(xiàng)目的最新版本，然后此基礎(chǔ)上進(jìn)行修改，最后向你的同事共享這些改動。傳統(tǒng)的方法是通過笨重的在線文件共享服務(wù)或者老舊的電郵附件，但是這兩種方式都是效率低下且容易出錯(cuò)。

Git 天生是為分布式工作設(shè)計(jì)的。如果你要參與到某個(gè)項(xiàng)目中，你可以克隆clone該項(xiàng)目的 Git 倉庫，然后就像這個(gè)項(xiàng)目只有你本地一個(gè)版本一樣對項(xiàng)目進(jìn)行修改。最后使用一些簡單的命令你就可以拉取pull其他開發(fā)者的修改，或者你可以把你的修改推送push給別人。現(xiàn)在不用擔(dān)心誰手上的是最新的版本，或者誰的版本又存放在哪里等這些問題了。全部人都是在本地進(jìn)行開發(fā)，然后向共同的目標(biāo)推送或者拉取更新。(或者不是共同的目標(biāo)，這取決于項(xiàng)目的開發(fā)方式)。

Git 界面

最原始的 Git 是運(yùn)行在 Linux 終端上的應(yīng)用軟件。然而，得益于 Git 是開源的，并且擁有良好的設(shè)計(jì)，世界各地的開發(fā)者都可以為 Git 設(shè)計(jì)不同的訪問界面。

Git 完全是免費(fèi)的，并且已經(jīng)打包在 Linux，BSD，Illumos 和其他類 Unix 系統(tǒng)中，Git 命令看起來像這樣：

$ git --version 
git version 2.5.3 

可能最著名的 Git 訪問界面是基于網(wǎng)頁的，像 GitHub、開源的 GitLab、Savannah、BitBucket 和 SourceForge 這些網(wǎng)站都是基于網(wǎng)頁端的 Git 界面。這些站點(diǎn)為面向公眾和面向社會的開源軟件提供了最大限度的代碼托管服務(wù)。在一定程度上，基于瀏覽器的圖形界面(GUI)可以盡量的減緩 Git 的學(xué)習(xí)曲線。下面的 GitLab 界面的截圖：

再者，第三方 Git 服務(wù)提供商或者獨(dú)立開發(fā)者甚至可以在 Git 的基礎(chǔ)上開發(fā)出不是基于 HTML 的定制化前端界面。此類界面讓你可以不用打開瀏覽器就可以方便的使用 Git 進(jìn)行版本管理。其中對用戶最透明的方式是直接集成到文件管理器中。KDE 文件管理器 Dolphin 可以直接在目錄中顯示 Git 狀態(tài)，甚至支持提交，推送和拉取更新操作。

Sparkleshare 使用 Git 作為其 Dropbox 式的文件共享界面的基礎(chǔ)。

想了解更多的內(nèi)容，可以查看 Git wiki，這個(gè)(長長的)頁面中展示了很多 Git 的圖形界面項(xiàng)目。

誰應(yīng)該使用 Git?

就是你!我們更應(yīng)該關(guān)心的問題是什么時(shí)候使用 Git?和用 Git 來干嘛?

我應(yīng)該在什么時(shí)候使用 Git 呢?我要用 Git 來干嘛呢?

想更深入的學(xué)習(xí) Git，我們必須比平常考慮更多關(guān)于文件格式的問題。

Git 是為了管理源代碼而設(shè)計(jì)的，在大多數(shù)編程語言中，源代碼就意味者一行行的文本。當(dāng)然，Git 并不知道你把這些文本當(dāng)成是源代碼還是下一部偉大的美式小說。因此，只要文件內(nèi)容是以文本構(gòu)成的，使用 Git 來跟蹤和管理其版本就是一個(gè)很好的選擇了。

但是什么是文本呢?如果你在像 Libre Office 這類辦公軟件中編輯一些內(nèi)容，通常并不會產(chǎn)生純文本內(nèi)容。因?yàn)橥ǔ?fù)雜的應(yīng)用軟件都會對原始的文本內(nèi)容進(jìn)行一層封裝，就如把原始文本內(nèi)容用 XML 標(biāo)記語言包裝起來，然后封裝在 Zip 包中。這種對原始文本內(nèi)容進(jìn)行一層封裝的做法可以保證當(dāng)你把文件發(fā)送給其他人時(shí)，他們可以看到你在辦公軟件中編輯的內(nèi)容及特定的文本效果。奇怪的是，雖然，通常你的需求可能會很復(fù)雜，就像保存 Kdenlive 項(xiàng)目文件，或者保存從 Inkscape 導(dǎo)出的SVG文件，但是，事實(shí)上使用 Git 管理像 XML 文本這樣的純文本類容是最簡單的。

如果你在使用 Unix 系統(tǒng)，你可以使用 file 命令來查看文件內(nèi)容構(gòu)成：

$ file ~/path/to/my-file.blah 
my-file.blah: ASCII text 
$ file ~/path/to/different-file.kra: Zip data (MIME type "application/x-krita") 

如果還是不確定，你可以使用 head 命令來查看文件內(nèi)容：

$ head ~/path/to/my-file.blah 

如果輸出的文本你基本能看懂，這個(gè)文件就很有可能是文本文件。如果你僅僅在一堆亂碼中偶爾看到幾個(gè)熟悉的字符，那么這個(gè)文件就可能不是文本文件了。

準(zhǔn)確的說：Git 可以管理其他格式的文件，但是它會把這些文件當(dāng)成二進(jìn)制大對象(blob)。兩者的區(qū)別是，在文本文件中，Git 可以明確的告訴你在這兩個(gè)快照(或者說提交)間有 3 行是修改過的。但是如果你在兩個(gè)提交commit之間對一張圖片進(jìn)行的編輯操作，Git 會怎么指出這種修改呢?實(shí)際上，因?yàn)閳D片并不是以某種可以增加或刪除的有意義的文本構(gòu)成，因此 Git 并不能明確的描述這種變化。當(dāng)然我個(gè)人是非常希望圖片的編輯可以像把文本“<sky>丑陋的藍(lán)綠色</sky>”修改成“<sky>漂浮著蓬松白云的天藍(lán)色</sky>”一樣的簡單，但是事實(shí)上圖片的編輯并沒有這么簡單。

經(jīng)常有人在 Git 上放入 png 圖標(biāo)、電子表格或者流程圖這類二進(jìn)制大型對象(blob)。盡管，我們知道在 Git 上管理此類大型文件并不直觀，但是，如果你需要使用 Git 來管理此類文件，你也并不需要過多的擔(dān)心。如果你參與的項(xiàng)目同時(shí)生成文本文件和二進(jìn)制大文件對象(如視頻游戲中常見的場景，這些和源代碼同樣重要的圖像和音頻材料)，那么你有兩條路可以走：要么開發(fā)出你自己的解決方案，就如使用指向共享網(wǎng)絡(luò)驅(qū)動器的引用;要么使用 Git 插件，如 Joey Hess 開發(fā)的 git annex，以及 Git-Media 項(xiàng)目。

你看，Git 真的是一個(gè)任何人都可以使用的工具。它是你進(jìn)行文件版本管理的一個(gè)強(qiáng)大而且好用工具，同時(shí)它并沒有你開始認(rèn)為的那么可怕。