Git【入門】這一篇就夠了

前言

歡迎關注公衆號，白嫖原創PDF，也能夠催更，微信搜：JavaPub，回覆：【666】

Git 在生產工做中是使用頻率很高的工具，但我發現不少文章只是對它作了簡單的提交命令說明，真正遇到 版本衝突或文件丟失 等問題又定位不到緣由，浪費大量時間。本篇文章較長，但都是在實際項目中用到的點。

閱讀本文大概須要6分鐘

[toc]

1.版本控制

1.1.什麼是版本控制

版本控制是一種記錄一個或若干文件內容變化，以便未來查閱特定版本修訂狀況的系統。除了項目，你能夠對任何類型的文件進行版本控制。

1.2.爲何版本控制

採用版本控制系統(VCS)是個明智的選擇。 有了它就能夠將某個文件回溯到以前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，能夠比較文件的變化細節，查出最後是誰修改了哪一個地方，從而找出致使怪異問題出現的緣由，又是誰在什麼時候報告了某個功能缺陷等等。 使用版本控制系統就算你對項目刪除、修改錯誤，這也沒有關係，你也照樣能夠很容易地就恢復到原先的樣子。但額外增長的工做量卻微乎其微。

1.3.本地版本控制

許多人習慣用複製整個項目目錄的方式來保存不一樣的版本，或許還會更名加上備份時間以示區別。 這麼作惟一的好處就是簡單，可是特別容易犯錯。 有時候會混淆所在的工做目錄，一不當心會寫錯文件或者覆蓋意想外的文件。並且不利於團隊協做。
爲了解決這個問題，人們好久之前就開發了許多種本地版本控制系統，大多都是採用某種簡單的數據庫來記錄文件的歷次更新差別。圖片來源 Git 官網。

其中最流行的一種叫作 RCS，現今許多計算機系統上都還看獲得它的蹤跡。 甚至在流行的 Mac OS X 系統上安裝了開發者工具包以後，也可使用 rcs 命令。 它的工做原理是在硬盤上保存補丁集(補丁是指文件修訂先後的變化)；經過應用全部的補丁，能夠從新計算出各個版本的文件內容。

1.2.集中化的版本控制

接下來人們又遇到一個問題，如何讓在不一樣系統上的開發者協同工做？ 因而，集中化的版本控制系統(Centralized Version Control Systems，簡稱 CVCS)應運而生。 諸如 CVS、Subversion(SVN) 以及 Perforce 等。
集中化的版本控制系統是單一的集中管理的服務器，保存全部文件的修訂版本，而協同工做的人們都經過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這已成爲版本控制系統的標準作法。如圖（來源 Git 官網）：

相對本地版本管理，集中化的版本控制每一個人均可以在必定程度上看到項目中的其餘人正在作些什麼。 而管理員也能夠輕鬆掌控每一個開發者的權限，而且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。

它也有以下詬病：

1. 單點故障
   若是宕機，誰都沒法提交更新，也就沒法協同工做。 若是中心數據庫所在的磁盤發生損壞，又沒有作恰當備份，毫無疑問將丟失全部數據——包括項目的整個變動歷史，只剩下人們在各自機器上保留的單獨快照。

2. 須要聯網
   爲何須要聯網？集中化的版本控制系統 倉庫集中在一臺服務器，也就受到服務器網絡環境的影響。

1.2.分佈式版本控制

因而分佈式版本控制系統(Distributed Version Control System，簡稱 DVCS)面世了。 Git 就是典型的分佈式版本控制。還有 Mercurial、Bazaar 以及 Darcs 等。

客戶端並不僅提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。 這麼一來，任何一處協同工做用的服務器發生故障，過後均可以用任何一個鏡像出來的本地倉庫恢復。 由於每一次的克隆操做，實際上都是一次對代碼倉庫的完整備份。圖片來源 Git 官網。

分佈式版本控制系統的優點不單是沒必要聯網這麼簡單，後面咱們還會看到 Git 極其強大的分支管理等功能。

2.認識 Git

2.1.Git 簡史

2002 年，Linux 內核開源項目整個項目組啓用一個專有的分佈式版本控制系統 BitKeeper 來管理和維護代碼。到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合做關係結束，他們收回了 Linux 內核社區無償使用 BitKeeper 的權力。 這就迫使 Linux 開源社區(特別是 Linux 的締造者 Linus Torvalds)基於使用 BitKeeper 時的經驗教訓，開發出本身的版本系統。

2.2.Git 與其餘版本控制系統區別

集中式的缺點：集中式版本控制系統最大的毛病就是必須聯網才能工做，若是在局域網內還好，帶寬夠大，速度夠快。

1. 分佈式版本控制系統根本沒有「中央服務器」，每一個人的電腦上都是一個完整的版本庫，這樣，你工做的時候，就不須要聯網了，由於版本庫就在你本身的電腦上。既然每一個人電腦上都有一個完整的版本庫。

比方說你在本身電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，大家倆之間只需把各自的修改推送給對方，就能夠互相看到對方的修改了。

2. 和集中式版本控制系統相比，分佈式版本控制系統的安全性要高不少，由於每一個人電腦裏都有完整的版本庫。

某一我的的電腦壞掉了沒關係，隨便從其餘人那裏複製一個就能夠了。而集中式版本控制系統的中央服務器要是出了問題，全部人都無法幹活了。

在實際使用分佈式版本控制系統的時候，其實不多在兩人之間的電腦上推送版本庫的修改，由於可能大家倆不在一個局域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。所以，分佈式版本控制系統一般也有一臺充當「中央服務器」的電腦，但這個服務器的做用僅僅是用來方便「交換」你們的修改，沒有它你們也同樣幹活，只是交換修改不方便而已。

2.2.1.Git 和其餘版本控制系統的存儲區別

Git的存儲方式是 快照技術 ,而其餘版本控制系統的存儲基本上都是 增量存儲。如下圖片來自網絡。

2.2.1.1.快照技術

Git在每次 git add 即將內容添加到 緩存區 時會進行一次快照，快照 就像給當時的整個目錄及文件照了一張相，在任什麼時候候經過快照就能將目錄及文件恢復到發起快照點的狀態。Git 是這樣生成快照的，對於沒有變化的文件，會生成一個引用指向原文件的位置以節省空間提升效率，對於變化了的文件則將整個文件存儲。git每一個版本存儲的是一個快照。

2.2.1.2.增量存儲

所謂 增量存儲 ,指的是除了第一個版本存儲的是每一個文件的完整內容，以後的版本存儲的是每一個文件相對於上一個版本對應文件的變化的內容。

2.3.Git 三種文件狀態

Git 在未進行 commit 操做以前，存在三種狀態：Untracked files，Changes not staged for commit 及 Changes to be committed ，每種狀態之間能夠隨意進行互相轉換。瞭解這三種狀態各自所對應的不一樣狀況，可以幫助你方便有效的使用 Git 來管理項目。

在 Git 中，文件狀態是個很是重要的概念。

爲了更清楚的說明 文件狀態 的概念，使用網絡上三張圖片。

• 初始化一個項目，也就是將項目所在目錄歸入Git的管理之下。假設項目目錄爲hello_world，初始化以後，在目錄下新建README.txt文件，接着，使用「git status」查看文件狀態，如圖

• 能夠看到，Git友好的標示出README.txt爲「Untracked files」，而且提示使用「git add <file>...」的命令將文件包含到待提交清單中。按照提示，使用「git add README.txt」命令，而後，使用「git status」查看文件狀態，如圖：

• 文件README.txt狀態變成了「Changes to be committed」，也就是說README.txt在暫存區域生成了快照，等待被提交。正如Git所提示的那樣，經過「git rm --cached README.txt」命令，能夠將文件狀態還原爲未暫存狀態，即回到「Untracked files」文件狀態。如今，README.txt已經能夠被提交到git目錄中了，可是暫時不提交。打開README.txt，向其中加些內容，保存以後，用「git status」查看，返回如圖信息：

能夠看到，除了以前的「Changes to be committed」狀態，如今又多了一條「Changes not staged for commit」狀態，代表文件已經修改，可是尚未放入暫存區域，也就是沒生成快照。若是如今進行commit操做，只是將修改以前的文件快照提交到了git目錄，必定記住：只有暫存區域的文件（即：文件狀態爲「Changes to be committed」）纔會被提交。正如提示，經過「git add README.txt」命令將已修改文件更新到暫存區域中，若是想撤銷修改，可使用「git checkout -- README.txt」命令。

3.Git 安裝

3.1.Linux 安裝

• Centos/RedHat 安裝

$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel

$ yum -y install git-core

$ git --version
git version 1.7.1

Linux 的其餘版本系統須要其餘方式安裝。

3.2.Windows 安裝

直接在官網下載。

另外一種是在 Github ，搜索 GitHub for Windows 項目。

4.Git 快速入門

4.1.獲取倉庫

• 第一種：

新建一個存項目文件夾，在 git bash 執行 git init ，項目文件夾下出現 .git 的子目錄。

• 第二種

從遠程代碼倉庫拉去一個現有的：git clone [url] 也能夠自定義本地倉庫名字 git clone [url] dirName

4.2.完整一次的提交流程

進入 Git 項目目錄

cd /myProject

提交全部修改到暫存區

git add .

提交暫存區修改內容到本地倉庫

git commit -m "提交描述"

推送到遠程倉庫

git push

如今就能夠拉去 JavaPub 的遠程倉庫了。

4.3.提交說明

• 忽略文件配置：.gitignore 文件
• 移除文件：git rm filename(從暫存區移除，而後提交)
• 查看文件狀態：git status

4.4.推送到遠程倉庫

• 推送到遠程倉庫：git push origin master 推送到遠程 master 分支

• 若是沒有遠程倉庫，如今想讓本地和遠程倉庫關聯，
  以下命令添加：git remote add origin <server> ,好比咱們要讓本地的一個倉庫和 Github 上建立的一個倉庫關聯能夠這樣 git remote add origin https://github.com/Rodert/test.git

如今就能夠將項目推送到遠程倉庫了。

4.5.提交歷史

有時咱們須要查詢之前的提交歷史，使用命令 git log。

只看某人提交記錄

git log --author=bob

4.6.撤銷操做

有時你提交過代碼以後，發現一個地方改錯了，你下次提交時不想保留上一次的記錄；或者你上一次的 commit message的描述有誤，這時候你可使用接下來的這個命令：git commit --amend。

git commit --amend

取消上一步操做，如 git add 、 git commit 以後。

git reset filename

4.7.分支

分支是用來將特性開發絕緣開來的。在你建立倉庫的時候，master 是默認的。在其餘分支上進行開發，完成後再將它們合併到主分支上。

不一樣的版本或系統模塊並行開發時，咱們通常會單獨創建一個分支進行開發，最後再合併到主分支。

• 新建本地分支

git branch test

• 切換到 test 分支

git checkout test

也能夠合併上面倆步，git checkout -b feature_x。

• 切換到 master 分支

git checkout master

• 合併分支 （可能有衝突）

git merge test

• 把新建的分支刪掉

git branch -d test

• 另外，也能夠把分支推送到遠程倉庫 git push <遠程主機名> <本地分支名>:<遠程分支名>

git push origin test:test

---

聲明：參考來源互聯網，有任何爭議能夠留言。站在前人的肩上，咱們才能看的更遠。

本教程純手打，致力於最實用教程，不須要什麼獎勵，只但願多多轉發支持。