Git算不算程序員的必備技能？

時間 2019-11-26

標籤 git 不算程序員必備技能欄目 Git 简体版

原文原文鏈接

點擊關注異步圖書，置頂公衆號git

天天與你分享 IT好書技術乾貨職場知識程序員

參與文末話題討論，每日贈送異步圖書。web

——異步小編算法

Git的背後有着一個很是精彩的成功故事。2005年4月，Linus Torvalds因不滿當時任何一個可用的開源版本控制系統，就親自着手實現了Git。shell

時至今日，若是咱們在Google中搜索「git version control」這幾個關鍵詞，都會看到數以百萬計的返回結果。Git已經儼然成爲了新型開源項目的一個標準。許多大型的開源項目都已經或正在計劃遷移到Git上來。Git算不算程序員的必備技能？答案是確定的。編程

爲何要用Git?

站在巨人的肩膀上，咱們要特別感謝Linus Torvalds、Junio C. Hamano以及Git項目的衆多提交者，是他們給開發者社區帶來了這個奇妙的工具。安全

Git容許咱們利用分支來開展工做：在一個由多個開發者並行協做的項目中，開發者各自會有不少不一樣的開發路線。Git的優點在於，它提供了一整套針對開發鏈的從新整合工具，以便咱們對其進行合併、變基和撿取等操做。

工做流上的靈活性：Git很是靈活。不但單一開發者能夠用它，敏捷團隊也能夠找到使用它工做的合適方法，甚至一個由衆多開發者在不一樣的工做地點參與的大型國際項目也能夠用它開發出一個很好的工做流。

適合奉獻合做：大多數開源項目所依靠的都是開發者的無私奉獻。所以，讓這種無私奉獻的方式儘量地簡單化是一件很是重要的事。而這在一個集中式的版本控制系統中一般是很難作到的，由於咱們不可能讓全部人都有權限去寫版本庫。但若是咱們使用Git，那麼每一個人都先能夠克隆一個獨立的工做版本庫，而後再對其進行後續的改動。

高性能：Git在處理擁有許多文件且歷史悠久的項目時速度也依然是很是快的。例如，使用Git將Linux內核源碼的當前版本切換到6年前的舊版本時，在一臺MacBook Air上所需的時間不到1分鐘。考慮這兩個版本之間有着超過200000次的提交和40000個更改文件，這已經足以讓人印象深入了。

強大的抗故障和抗攻擊能力：因爲項目歷史被分散存儲在多個分佈式版本庫中，所以數據嚴重流失的可能性不大。再加上版本庫中有着巧妙簡單的數據結構，這確保了其中的數據即便在遙遠的將來也仍然會被正確地解釋。並且，它還使用了統一的加密校驗，這使得攻擊者難以對版本庫進行篡改。

離線開發與多點開發：分佈式的體系結構可使得離線開發或者邊旅行邊開發的方式變得很是容易。並且該結構在多點開發模式下，咱們既不須要設置中央服務器，也不須要固定的網絡鏈接。

強大的開源社區：除官方提供的詳細文檔外，你還能夠在該社區找到無數相關的手冊、論壇、維基網站等，另外還有各類工具生態系統、託管平臺、出版物、服務以及針對各個開發環境的插件，整個社區都正在茁壯成長。

可擴展性：Git爲用戶提供了許多實用命令，其中包括了能使咱們更便於直接訪問其遠程版本庫的命令。這可讓Git變得很是靈活，這種靈活性將容許其各類獨立應用提供比默認的Git版本更爲強大的功能。

爲何要用工做流

Git很是靈活。可爲多種不一樣的角色所用，從偶爾須要版本化少許shell腳本的單一系統管理員，到Linux內核項目中的上百個開發人員，一切皆有可能。固然，這種靈活性不是沒有代價的。在開始用Git來開展工做以前，你還必需要作一組決定。例如如下幾種。服務器

Git中當然已是分佈式版本庫。但你是真的打算只在本地工做，仍是更願意創建一箇中央版本庫？網絡

Git支持push和pull兩種數據傳輸類型，但咱們須要同時使用它們嗎？若是讓你選，你會選哪個？爲何不是另外一個？數據結構

分支與合併是Git中兩個強大的功能。可是，咱們應該開多少個分支呢？是根據每一個軟件功能來開？仍是針對每一個發行版來開？仍是隻該有一個分支？

爲了便於入門，下面咱們來總結一下工做流及其做用。

工做流指的是相關項目的平常操做規程。

工做流會給出具體的步驟。

工做流會顯示必要的命令和選項。

工做流很是適用於密切的團隊合做，而目前的這些現代軟件項目一般就出自這樣的合做。

一些工做流可能並非目標問題惟一正確的解決方案，但它們是一個很好的起點，咱們能夠從中爲本身的項目開發出高效的工做流。

咱們之因此會重點介紹商業項目中敏捷開發團隊的工做，是由於咱們相信目前許多專業開發者（包括做者）都處於這樣的工做環境中。固然，這裏並不包括那些具備特殊要求的大型項目，由於這些項目一般有着很誇張的工做流，並且咱們相信這些也不是大多數開發者會感興趣的項目。另外，這裏也不包括那些開源項目的開發，雖然這些項目也能夠用Git規劃出一個頗有意思的工做流。

分佈式版本控制，有什麼過人之處

在具體探討分佈式版本控制的概念以前，讓咱們先來快速回顧一下傳統的集中式版本控制架構。

圖1.1中所顯示的就是一個集中式版本控制系統（例如CVS或Subversion）的典型佈局。每一個開發者都在他或她本身的計算機上有一個包含全部項目文件的工做目錄（即工做區）。當該開發者在本地作了修改以後，他或她就會按期將修改提交給某臺中央服務器。而後，開發者在執行更新操做的同時也會從該服務器上撿取出其餘開發者所作的修改。這臺中央服務器上存儲着這些文件（即版本庫）的當前版本和歷史版本。所以，這些被並行開發的分支，以及各類被命名（標記）的版本都將會被集中管理。

圖1.1　集中式版本控制

而在分佈式版本控制系統（見圖1.2）中，開發者環境與服務器環境之間是沒有分隔的。每個開發者都同時擁有一個用於當前文件操做的工做區與一個用於存儲該項目全部版本、分支以及標籤的本地版本庫（咱們稱其爲一份克隆）。每一個開發者的修改都會被載入成一次次的新版本提交(commit), 首先提交到其本地版本庫中。而後，其餘開發者就會當即看到新的版本。經過推送（push）和拉回（pull）命令，咱們能夠將這些修改從一個版本庫傳送到另外一個版本庫中。這樣一來，從技術上來看，這裏全部的版本庫在分佈式架構上的地位是同等的。所以從理論上來說，咱們再也不須要藉助服務器，就能夠將某一臺開發工做機上所作的全部修改直接傳送給另外一開發工做機。固然在具體實踐中，Git中的服務器版本庫也扮演了重要的角色，例如如下這些特型版本庫。

圖1.2　分佈式版本控制

項目版本庫（blessed repository）：該版本庫主要用於存儲由「官方」建立併發行的版本。

共享版本庫（shared repository）：該版本庫主要用於開發團隊內人員之間的文件交換。在小型項目中，項目版本庫自己就能夠勝任這一角色了。但在多點開發的條件下，咱們可能就會須要幾個這樣的專用版本庫。

工做流版本庫（workflow repository）：工做流版本庫一般只用於填充那些表明工做流中某種特定進展狀態的修改，例如審覈經過後的狀態等。

派生版本庫（fork repository）：該版本庫主要用於從開發主線分離出某部份內容（例如，分離出那些開發耗時較長，不適合在一個普通發佈週期中完成的內容），或者隔離出可能永遠不會被包含在主線中的、用於實驗的那部分開發進展。

下面，咱們再來看看分佈式系統相對於集中式的優勢有哪些。

高性能：幾乎全部的操做都無需進行網絡訪問，都可直接在本地執行。

高效的工做方式：開發者可經過多個本地分支在不一樣任務之間進行快速切換。

離線功能：開發者能夠在沒有服務器鏈接的狀況下執行提交、建立分支、版本標籤等操做。以後再將其上傳服務器。

靈活的開發進程：咱們能夠在團隊和公司中爲其餘部門創建專用的版本庫，例如爲方便與測試人員交流而建的版本庫。這樣相關修改就很容易發佈，由於只是特定版本庫上的一次推送。

備份做用：因爲每一個開發者都持有一份擁有完整歷史版本的版本庫副本，因此因服務器故障而致使數據丟失的可能性是微乎其微的。

可維護性：對於那些難以對付的重構工做，咱們能夠在將成功傳送給其原始版本庫以前，先在該版本庫的副本上嘗試一下。

版本庫，分佈式的基礎所在

其實，版本庫本質上就是一個高效的數據存儲結構而已，由如下部分組成。

文件（即blob）：這裏既包含了文本也包含了二進制數據，這些數據將不以文件名的形式被保存。

目錄（即Tree）：目錄中保存的是與文件名相關聯的內容，其中也會包含其餘目錄。

版本（即commit）：每個版本所定義的都是相應目錄的某個可恢復的狀態。每當咱們建立一個新的版本時，其做者、時間、註釋以及其以前的版本都將會被保存下來。

對於全部的數據，它們都會被計算成一個十六進制散列值（例如像1632acb65b01 c6b621d6e1105205773931bb1a41這樣的值）。這個散列值將會被用做相關對象的引用，以及往後恢復數據時所需的鍵值（見圖1.3）。

圖1.3　版本庫中的對象存儲

也就是說，一個提交對象的散列值實際上就是它的「版本號」，若是咱們持有某一提交的散列值，就能夠用它來檢查對應版本是否存在於某一版本庫中。若是存在，咱們就能夠將其恢復到當前工做區相應的目錄中。若是該版本不存在，咱們也能夠從其餘版本庫中單獨導入（拉回）該提交所引用的所有對象。

接下來，咱們來看看採用這種散列值和這種既定的版本庫結構究竟有哪些優點。

高性能：經過散列值來訪問數據是很是快的。

冗餘度——釋放存儲空間：相同的文件內容只需存儲一次便可。

分佈式版本號：因爲相關散列值是根據文件，做者和日期來計算的，因此版本也能夠「離線」產生，不用擔憂未來會所以而發生版本衝突。

版本庫間的高效同步：當咱們將某一提交從一個版本庫傳遞給另外一個版本庫時，只須要傳送那些目標版本庫中不存在的對象便可。而正是由於有了散列值的幫助，咱們才能很快地判斷相關對象是否已經存在。

數據完整性：因爲散列值是根據數據的內容來計算的，因此咱們能夠隨時經過Git來查看某一散列值是否與相關數據匹配。以檢測該數據上可能的意外變化或惡意操做。

自動重命名檢測：被重命名的文件能夠被自動檢測到，由於根據該文件內容計算出的散列值並無發生變化。也正由於如此，Git中並無專用的重命名命令，只需移動命令便可。

分支的建立與合併很簡單

對於大多數版本控制系統來講，分支的建立與合併一般會因其特殊性而被認爲是高級拓展操做。但因爲Git最初就是爲了方便那些散落在世界各地的Linux內核開發者而建立的，合併多方努力的結果一直都是其面臨的最大挑戰之一，因此Git的設計目標之一就是要讓分支的建立與合併操做變得儘量地簡單且安全。

在下面的圖1.4中，咱們向你展現了開發者是如何經過建立分支的方式來進行並行開發的。圖中的每個點都表明了該項目的一個版本（即commit）。而因爲在Git中，咱們只能對整個項目進行版本化，因此每一個點同時也表明了屬於同一版本的各個文件。

圖1.4　因開發者的並行開發而出現的分支建立操做

如上所示，圖中兩位開發者的起點是同一個版本。以後兩人各自作了修改，並提交了修改。這時候，對於這兩位開發者各自的版本庫來講，該項目已經有了兩個不一樣的版本。也就是說，他們在這裏建立了兩個分支。接下來，若是其中一個開發者想要導入另外一我的的修改，他/她就能夠用Git來進行版本合併。若是合併成功了，Git就會建立一個合併提交，其中會包含兩位開發者所作的修改。這時若是另外一位開發者也取回了這一提交，兩位開發者的項目就又回到了同一個版本。

在上面的例子中，分支的建立是非計劃性的，其緣由僅僅是兩個開發者在並行開發同一個軟件罷了。在Git中，咱們固然也能夠開啓有針對性的分支，即顯式地建立一個分支（見圖1.5）。顯式分支一般主要用於協調某一種功能性的並行開發。