Git 系列（一）：什麼是 Git

導讀	若是你剛步入開源的世界，你頗有可能會遇到一些在 Git 上託管代碼或者發佈使用版本的開源軟件。事實上，無論你知道與否，你都在使用基於 Git 進行版本管理的軟件：Linux 內核(就算你沒有在手機或者電腦上使用 Linux，你正在訪問的網站也是運行在 Linux 系統上的)，Firefox、Chrome 等其餘不少項目都經過 Git 代碼庫和世界各地開發者共享他們的代碼。

 

換個角度來講，你是否僅僅經過 Git 就能夠和其餘人共享你的代碼?你是否能夠在家裏或者企業裏私有化的使用 Git?你必需要經過一個 GitHub 帳號來使用 Git 嗎?爲何要使用 Git 呢?Git 的優點又是什麼?Git 是我惟一的選擇嗎?這對 Git 全部的疑問都會把咱們搞的一腦漿糊。

所以，忘記你之前所知的 Git，讓咱們從新走進 Git 世界的大門。

什麼是版本控制系統?

Git 首先是一個版本控制系統。如今市面上有不少不一樣的版本控制系統：CVS、SVN、Mercurial、Fossil 固然還有 Git。

不少像 GitHub 和 GitLab 這樣的服務是以 Git 爲基礎的，可是你也能夠只使用 Git 而無需使用其餘額外的服務。這意味着你能夠以私有或者公有的方式來使用 Git。

若是你曾經和其餘人有過任何電子文件方面的合做，你就會知道傳統版本管理的工做流程。開始是很簡單的：你有一個原始的版本，你把這個版本發送給你的同事，他們在接收到的版本上作了些修改，如今大家有兩個版本了，而後他們把他們手上修改過的版本發回來給你。你把他們的修改合併到你手上的版本中，如今兩個版本又合併成一個最新的版本了。

而後，你修改了你手上最新的版本，同時，你的同事也修改了他們手上合併前的版本。如今大家有 3 個不一樣的版本了，分別是合併後最新的版本，你修改後的版本，你同事手上繼續修改過的版本。至此，大家的版本管理工做開始變得愈來愈混亂了。

正如 Jason van Gumster 在他的文章中指出 即便是藝術家也須要版本控制，並且已經在個別人那裏發現了這種趨勢變化。不管是藝術家仍是科學家，開發一個某種實驗版本是並不鮮見的;在你的項目中，可能有某個版本大獲成功，把項目推向一個新的高度，也可能有某個版本慘遭失敗。所以，最終你不可避免的會建立出一堆名爲project_justTesting.kdenlive、project_betterVersion.kdenlive、project_best_FINAL.kdenlive、project_FINAL-alternateVersion.kdenlive 等相似名稱的文件。

無論你是修改一個 for 循環，仍是一些簡單的文本編輯，一個好的版本控制系統都會讓咱們的生活更加的輕鬆。

Git 快照

Git 能夠爲項目建立快照，而且存儲這些快照爲惟一的版本。

若是你將項目帶領到了一個錯誤的方向上，你能夠回退到上一個正確的版本，而且開始嘗試另外一個可行的方向。

若是你是和別人合做開發，當有人向你發送他們的修改時，你能夠將這些修改合併到你的工做分支中，而後你的同事就能夠獲取到合併後的最新版本，並在此基礎上繼續工做。

Git 並非魔法，所以衝突仍是會發生的(「你修改了某文件的最後一行，可是我把這行整行都刪除了;咱們怎樣處理這些衝突呢?」)，可是整體而言，Git 會爲你保留了全部更改的歷史版本，甚至容許並行版本。這爲你保留了以任何方式處理衝突的能力。

分佈式 Git

在不一樣的機器上爲同一個項目工做是一件複雜的事情。由於在你開始工做時，你想要得到項目的最新版本，而後此基礎上進行修改，最後向你的同事共享這些改動。傳統的方法是經過笨重的在線文件共享服務或者老舊的電郵附件，可是這兩種方式都是效率低下且容易出錯。

Git 天生是爲分佈式工做設計的。若是你要參與到某個項目中，你能夠克隆clone該項目的 Git 倉庫，而後就像這個項目只有你本地一個版本同樣對項目進行修改。最後使用一些簡單的命令你就能夠拉取pull其餘開發者的修改，或者你能夠把你的修改推送push給別人。如今不用擔憂誰手上的是最新的版本，或者誰的版本又存放在哪裏等這些問題了。所有人都是在本地進行開發，而後向共同的目標推送或者拉取更新。(或者不是共同的目標，這取決於項目的開發方式)。

Git 界面

最原始的 Git 是運行在 Linux 終端上的應用軟件。然而，得益於 Git 是開源的，而且擁有良好的設計，世界各地的開發者均可覺得 Git 設計不一樣的訪問界面。

Git 徹底是免費的，而且已經打包在 Linux，BSD，Illumos 和其餘類 Unix 系統中，Git 命令看起來像這樣：

$ git --version
git version 2.5.3

可能最著名的 Git 訪問界面是基於網頁的，像 GitHub、開源的 GitLab、Savannah、BitBucket 和 SourceForge 這些網站都是基於網頁端的 Git 界面。這些站點爲面向公衆和麪向社會的開源軟件提供了最大限度的代碼託管服務。在必定程度上，基於瀏覽器的圖形界面(GUI)能夠儘可能的減緩 Git 的學習曲線。下面的 GitLab 界面的截圖：

 

再者，第三方 Git 服務提供商或者獨立開發者甚至能夠在 Git 的基礎上開發出不是基於 HTML 的定製化前端界面。此類界面讓你能夠不用打開瀏覽器就能夠方便的使用 Git 進行版本管理。其中對用戶最透明的方式是直接集成到文件管理器中。KDE 文件管理器 Dolphin 能夠直接在目錄中顯示 Git 狀態，甚至支持提交，推送和拉取更新操做。

 

 

Sparkleshare 使用 Git 做爲其 Dropbox 式的文件共享界面的基礎。

 

 

想了解更多的內容，能夠查看 Git wiki，這個(長長的)頁面中展現了不少 Git 的圖形界面項目。

 

誰應該使用 Git?

就是你!咱們更應該關心的問題是何時使用 Git?和用 Git 來幹嗎?

我應該在何時使用 Git 呢?我要用 Git 來幹嗎呢?

想更深刻的學習 Git，咱們必須比日常考慮更多關於文件格式的問題。

Git 是爲了管理源代碼而設計的，在大多數編程語言中，源代碼就意味者一行行的文本。固然，Git 並不知道你把這些文本當成是源代碼仍是下一部偉大的美式小說。所以，只要文件內容是以文本構成的，使用 Git 來跟蹤和管理其版本就是一個很好的選擇了。

可是什麼是文本呢?若是你在像 Libre Office 這類辦公軟件中編輯一些內容，一般並不會產生純文本內容。由於一般複雜的應用軟件都會對原始的文本內容進行一層封裝，就如把原始文本內容用 XML 標記語言包裝起來，而後封裝在 Zip 包中。這種對原始文本內容進行一層封裝的作法能夠保證當你把文件發送給其餘人時，他們能夠看到你在辦公軟件中編輯的內容及特定的文本效果。奇怪的是，雖然，一般你的需求可能會很複雜，就像保存 Kdenlive 項目文件，或者保存從 Inkscape 導出的SVG文件，可是，事實上使用 Git 管理像 XML 文本這樣的純文本類容是最簡單的。

若是你在使用 Unix 系統，你可使用 file 命令來查看文件內容構成：

$ 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 命令來查看文件內容：

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

若是輸出的文本你基本能看懂，這個文件就頗有多是文本文件。若是你僅僅在一堆亂碼中偶爾看到幾個熟悉的字符，那麼這個文件就可能不是文本文件了。

準確的說：Git 能夠管理其餘格式的文件，可是它會把這些文件當成二進制大對象(blob)。二者的區別是，在文本文件中，Git 能夠明確的告訴你在這兩個快照(或者說提交)間有 3 行是修改過的。可是若是你在兩個提交commit之間對一張圖片進行的編輯操做，Git 會怎麼指出這種修改呢?實際上，由於圖片並非以某種能夠增長或刪除的有意義的文本構成，所以 Git 並不能明確的描述這種變化。固然我我的是很是但願圖片的編輯能夠像把文本「<sky>醜陋的藍綠色</sky>」修改爲「<sky>漂浮着蓬鬆白雲的天藍色</sky>」同樣的簡單，可是事實上圖片的編輯並無這麼簡單。

常常有人在 Git 上放入 png 圖標、電子表格或者流程圖這類二進制大型對象(blob)。儘管，咱們知道在 Git 上管理此類大型文件並不直觀，可是，若是你須要使用 Git 來管理此類文件，你也並不須要過多的擔憂。若是你參與的項目同時生成文本文件和二進制大文件對象(如視頻遊戲中常見的場景，這些和源代碼一樣重要的圖像和音頻材料)，那麼你有兩條路能夠走：要麼開發出你本身的解決方案，就如使用指向共享網絡驅動器的引用;要麼使用 Git 插件，如 Joey Hess 開發的 git annex，以及 Git-Media 項目。

你看，Git 真的是一個任何人均可以使用的工具。它是你進行文件版本管理的一個強大並且好用工具，同時它並無你開始認爲的那麼可怕。

原文來自：http://os.51cto.com/art/201608/515456.htm

本文地址：http://www.linuxprobe.com/git1.html