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 並不能明確的描述這種變化。當然我個人是非常希望圖片的編輯可以像把文本「醜陋的藍綠色」修改成「漂浮著蓬鬆白雲的天藍色」一樣的簡單，但是事實上圖片的編輯並沒有這麼簡單。

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

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

via: https://opensource.com/resources/what-is-git

作者：Seth Kenlon 譯者：cvsher 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive