Git【入門】這一篇就夠了

前言

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

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

閱讀本文大概需要6分鐘

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，這時，你們倆之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。

1. 和集中式版本控制系統相比，分散式版本控制系統的安全性要高很多，因為每個人電腦裡都有完整的版本庫。

某一個人的電腦壞掉了不要緊，隨便從其他人那裡複製一個就可以了。而集中式版本控制系統的中央伺服器要是出了問題，所有人都沒法幹活了。

在實際使用分散式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，因為可能你們倆不在一個區域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。因此，分散式版本控制系統通常也有一臺充當“中央伺服器”的電腦，但這個伺服器的作用僅僅是用來方便“交換”大家的修改，沒有它大家也一樣幹活，只是交換修改不方便而已。

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...”的命令將檔案包含到待提交清單中。按照提示，使用“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

現在就可以拉去 的遠端倉庫了。

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

現在就可以將專案推送到遠端倉庫了。

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

宣告：參考來源網際網路，有任何爭議可以留言。站在前人的肩上，我們才能看的更遠。

本教程純手打，致力於最實用教程，不需要什麼獎勵，只希望多多轉發支援。