g4e 是 Git for Enterprise Developer的簡寫,這個系列文章會統一使用g4e做爲標識,便於你們查看和搜索。git
章節目錄github
前言算法
1. 基礎篇:安全
Git是當前最棒的版本控制系統,已經迅速成爲了事實的業界標準,如下是Stackoverflow網站在過去幾年中針對版本控制系統使用狀況的統計,你能夠明顯看出Git所佔的絕對領導位置。服務器
具體數據請參考:微信
• https://insights.stackoverflow.com/survey/2015
• https://insights.stackoverflow.com/survey/2017markdown
Git和其餘版本管理系統最大的區別在於它是一種分佈式的版本管理系統(DVCS),這主要是針對相似SVN, TFVC或者ClearCase這種集中式版本管理系統(CVCS)而言的。簡單來講,每一個Git存儲庫都是一份完整的代碼,歷史記錄以及分支的集合,而CVCS系統只在服務器上保存全部這些信息,而在本地通常只有當前版本和至多一個歷史版本。這種能力賦予了開發人員很是靈活的工做方式,由於分支/查找歷史/比較/合併等操做都不須要經過服務器進行,就能夠更爲輕鬆的脫機工做或者遠程工做;同時在鏈接到網絡的時候又能夠和其餘人共享代碼。網絡
Git 的靈活性和用戶接受度使之成爲任何團隊的首選。 如今,許多開發者和大學畢業生都已知道如何使用 Git。Git 的用戶社區中已有許多資源可用來培訓開發者,同時 Git 的用戶接受度使得用戶能夠在須要時輕鬆得到幫助。 幾乎全部的開發工具和技術棧都支持 Git,Git 命令行工具能夠在全部主要操做系統上運行。對於企業來講,若是不使用Git會讓那些新入職的開發者感到很是不適應,而且大幅度下降他們的開發效率,我曾將見到過開發者由於應聘企業使用老舊的開發工具而拒絕接受企業的Offer。運維
每當經過git保存修改時,Git 會建立一個提交 (commit)。 提交就是在某一個時間點全部文件改動的快照。 若是在下一個提交中文件沒有變化,Git 會使用以前存儲的文件。 每個提交都針對前一個提交保存一個連接,這種連接關係造成了一個開發歷史的數據鏈路。ssh
這種連接關係讓咱們能夠將代碼還原爲之前的提交、檢查兩個提交的文件變化,並能查看什麼時候在哪裏進行了更改等信息。 每一個提交在 Git 中都有一個惟一的標識 (commit id),這個id是經過對提交的內容執行加密哈希算法得出的。 因爲一切都已通過哈希處理,所以 Git 必定能夠檢測到更改、信息丟失或文件損壞。
Git分支與傳統版本管理系統不一樣,並不會在文件系統中建立重複的文件,而是經過修改當前文件所指向的具體版本(commit id)來實現的,因此你沒必要切換文件夾就能夠因此切換到任何分支上工做。
Git 中的文件有如下三種狀態:已修改(modified)、已暫存(staged)或已提交(committed)。 首次修改文件時,更改只存在於工做目錄中。 這些更改還不屬於提交或開發歷史記錄。 必須暫存(stage)要包含在提交中的已更改文件(能夠省略其中某些文件)才能將改動提交到Git。 暫存區域包含下一個提交將包含的全部更改。 對暫存文件感到滿意後,你就能夠提交(commit)這些文件,併爲提交添加描述信息。 這個提交就成爲開發歷史記錄的一部分了。
每一個人都有本身的代碼本地副本,能夠同時在本身的分支上工做。 你也能夠脫機使用 Git,由於幾乎全部操做都是在本地執行。
藉助分支,能夠靈活地進行同步開發。 主分支(master)做爲發佈版本的穩定代碼。 功能分支(feature branch)包含正在進行的工做,完成後將合併到主分支中。 經過將主分支與正在進行的開發分隔開來,能夠更好地管理穩定代碼,並更爲高效安全的發佈代碼。
由於 Git 用戶接受度很是高,它已被集成到大多數工具和產品中。 全部主流的 IDE 都內置有 Git 支持,還有不少工具提供了與 Git 集成的持續集成、持續部署、自動測試、工做項跟蹤、指標和報表功能。 這種集成簡化了平常工做流,下降了企業開發中工具二次開發,集成和定製的需求。
Git 做爲開放源代碼管理系統,已經成爲版本控制系統的業界標準,爲團隊提供所需的一切工具和資源。 相比其餘版本控制系統,Git 的社區支持很是強大,你能夠在須要時輕鬆得到幫助。
將 Git 與其餘工具配合使用,能夠鼓勵團隊協做、同時確保策略的實行、實現自動化,並能提升工做的可見性和可跟蹤性,從而提升團隊的工做效率。 你能夠單獨選擇不一樣的版本控制系統、工做項跟蹤系統以及持續集成和部署工具。 也能夠選擇 Visual Studio Team Services / Team Foundation Server 做爲端到端的管理工具,團隊具有很是高的自主性和靈活性。
使用拉取請求能夠確保代碼檢視過程的有效,而後再將它們合併到主分支中。 在拉取請求中進行的討論很是有價值,可確保代碼質量並促進團隊成員相互學習和協做。 Visual Studio Team Services / Team Foundation Server 提供了很是棒的拉取請求體驗,你能夠瀏覽文件更改、發表意見、檢查提交、查看生成,並能經過社交化投票來批准代碼合併。
分支策略是 Visual Studio Team Services / Team Foundation Server中提供一項有效保持主分支(master)代碼質量的策略機制,讓團隊能夠經過配置靈活的策略實現對主分支的保護,好比:不容許直接向主分支提交代碼,必須通過代碼檢視才能合併,必須通過特定人員批准才能合併,必須解決全部代碼檢視意見才能合併等一系列很是有效的保護手段;同時也容許你本身定製更加複雜的策略規則來適配團隊的不一樣訴求。
到這裏,咱們對Git的基本工做原理和它的優點具有了一些瞭解。下一章中咱們將開始搭建Git操做環境。
相關文章:
請關注微信公衆號 【devopshub】,獲取更多關於DevOps研發運維一體化的信息