git&github

1、版本控制

　　假設你在的公司要上線一個新功能，大家開發團隊爲實現這個新功能，寫了大約5000行代碼，上線沒2天，就發現這個功能用戶並不喜歡，你老闆讓你去掉這個功能。

　　急須要一個工具，幫你記錄每次對代碼作了哪些修改，而且能夠輕易的把代碼回滾到歷史上的某個狀態。 這個神奇的工具就叫作版本控制。 版本控制工具主要實現如下兩個功能：

一、版本管理

　　在開發中，這是剛需，必須容許能夠很容易對產品的版本進行任意回滾，版本控制工具實現這個功能的原理簡單來說，就是你每修改一次代碼，它就幫你作一次快照。

二、協做開發

　　一個複雜點的軟件，每每不是一個開發人員能夠搞定的，公司爲加快產品開發速度，會招聘一堆跟你同樣的開發人員開發這個產品。開發人員間來回copy代碼，很快就亂了， 因此此時亟需一個工具，能確保一直存儲最新的代碼庫，全部人的代碼應該和最新的代碼庫保持一致。

2、常見版本管理工具

一、VSS-- Visual Source Safe

　　此工具是Microsoft提供的，是使用的至關廣泛的工具之一，他能夠與VS.net進行無縫集成，成爲了獨立開發人員和小型開發團隊所適合的工具，基本上Window平臺上開發的中小型企業，當規模較大後，其性能一般是沒法忍受的，對分支與並行開發支持的比較有限。

二、CVS--Concurrent Versions System

　　此工具是一個開源工具，與後面提到的SVN是同一個廠家：Collab.Net提供的。

　　CVS是源於unix的版本控制工具，對於CVS的安裝和使用最好對unix的系統有所瞭解能更容易學習，CVS的服務器管理須要進行各類命令行操做。目前，CVS的客戶端有winCVS的圖形化界面，服務器端也有CVSNT的版本，易用性正在提升。

　　此工具是至關著名，使用得至關普遍的版本控制工具之一，使用成熟的「Copy-Modify-Merge"開發模型，能夠大大的提升開發效率，適合於項目比較大，產品發佈頻繁，分支活動頻繁的中大型項目。

三、SVN --CollabNet Subversion

　　此工具是在CVS 的基礎上，由CollabNet提供開發的，也是開源工具,應用比較普遍。

　　他修正cvs的一些侷限性，適用範圍同cvs，目前有一些基於SVN的第三方工具，如TortoiseSVN,是其客戶端程序，使用的也至關普遍。在權限管理，分支合併等方面作的很出色，他能夠與Apache集成在一塊兒進行用戶認證。

　　不過在權限管理方面目前尚未個很好用的界面化工具，SVNManger對於已經使用SVN進行配置的項目來講，基本上是沒法應用的，但對於從頭開始的項目是能夠的，功能比較強大，可是搭建svnManger比較麻煩。

　　是一個跨平臺的軟件，支持大多數常見的操做系統。做爲一個開源的版本控制系統,Subversion 管理着隨時間改變的數據。 這些數據放置在一箇中央資料檔案庫中。 這個檔案庫很像一個普通的文件服務器, 不過它會記住每一次文件的變更。 這樣你就能夠把檔案恢復到舊的版本, 或是瀏覽文件的變更歷史。Subversion 是一個通用的系統, 可用來管理任何類型的文件, 其中包括了程序源碼。

4. GIT

　　由於最初是從Linux起家的，很是依賴文件系統的一些特性，這些在 Linux 下表現的很好，而 Windows 下特別糟糕Git。

　　Git是一個開源的分佈式版本控制系統，用以有效、高速的處理從很小到很是大的項目版本管理。

　　Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。

　　Torvalds 開始着手開發 Git 是爲了做爲一種過渡方案來替代 BitKeeper，後者以前一直是 Linux 內核開發人員在全球使用的主要源代碼工具。開放源碼社區中的有些人以爲 BitKeeper 的許可證並不適合開放源碼社區的工做，所以 Torvalds 決定着手研究許可證更爲靈活的版本控制系統。儘管最初 Git 的開發是爲了輔助 Linux 內核開發的過程，可是咱們已經發如今不少其餘自由軟件項目中也使用了 Git。例如 最近就遷移到 Git 上來了，不少 Freedesktop 的項目也遷移到了 Git 上。

五、BitKeeper

　　是由BitMover公司提供的，BitKeeper自稱是「分佈式」可擴縮SCM系統。

　　不是採用C/S結構，而是採用P2P結構來實現的，一樣支持變動任務，全部變動集的操做都是原子的，與svn、cvs一致。

3、GIT入門

一、GIT和Github是什麼？二者是什麼關係？

　　Git是一個免費、開源的版本控制軟件。

　　Github是全球最大的社交編程及代碼託管網站（https://github.com/）；Github能夠託管各類git庫，並提供一個web界面（用戶名.github.io/倉庫名）

　　二者關係：Git是版本控制軟件；Github是項目代碼託管的平臺，藉助git來管理項目代碼。

二、GIT下載安裝

　　在你開始使用 Git 前，須要將它安裝在你的計算機上。 即使已經安裝，最好將它升級到最新的版本。 你能夠經過軟件包或者其它安裝程序來安裝，或者下載源碼編譯安裝。

（1）Linux上安裝

　　若是你想在 Linux 上用二進制安裝程序來安裝 Git，可使用發行版包含的基礎軟件包管理工具來安裝。 若是以 Fedora 上爲例，你可使用 yum：

$ sudo yum install git

　　若是你在基於 Debian 的發行版上，請嘗試用 apt-get：

$ sudo apt-get install git

　　要了解更多選擇，Git 官方網站上有在各類 Unix 風格的系統上安裝步驟，網址爲 http://git-scm.com/download/linux。

（2）Mac上安裝

　　在 Mac 上安裝 Git 有多種方式。 最簡單的方法是安裝 Xcode Command Line Tools。 Mavericks （10.9） 或更高版本的系統中，在 Terminal 裏嘗試首次運行 git 命令便可。 若是沒有安裝過命令行開發者工具，將會提示你安裝。

　　若是你想安裝更新的版本，可使用二進制安裝程序。 官方維護的 OSX Git 安裝程序能夠在 Git 官方網站下載，網址爲 http://git-scm.com/download/mac。

　　

Figure 7. Git OS X 安裝程序.

　　你也能夠將它做爲 GitHub for Mac 的一部分來安裝。 它們的圖形化 Git 工具備一個安裝命令行工具的選項。 你能夠從 GitHub for Mac 網站下載該工具，網址爲 http://mac.github.com。

（3）windows上安裝

　　在 Windows 上安裝 Git 也有幾種安裝方法。 官方版本能夠在 Git 官方網站下載。 打開 http://git-scm.com/download/win，下載會自動開始。 要注意這是一個名爲 Git for Windows的項目（也叫作 msysGit），和 Git 是分別獨立的項目；更多信息請訪問 http://msysgit.github.io/。

　　另外一個簡單的方法是安裝 GitHub for Windows。 該安裝程序包含圖形化和命令行版本的 Git。 它也能支持 Powershell，提供了穩定的憑證緩存和健全的 CRLF 設置。 稍後咱們會對這方面有更多瞭解，如今只要一句話就夠了，這些都是你所須要的。 你能夠在 GitHub for Windows 網站下載，網址爲 http://windows.github.com。

（4）源代碼安裝

　　若是你想從源碼安裝 Git，須要安裝 Git 依賴的庫：curl、zlib、openssl、expat，還有libiconv。 若是你的系統上有 yum （如 Fedora）或者 apt-get（如基於 Debian 的系統），可使用如下命令之一來安裝最小化的依賴包來編譯和安裝 Git 的二進制版：

$ sudo yum install curl-devel expat-devel gettext-devel \
    openssl-devel zlib-devel
$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
    libz-dev libssl-dev

　　爲了可以添加更多格式的文檔（如 doc, html, info），你須要安裝如下的依賴包：

$ sudo yum install asciidoc xmlto docbook2x
$ sudo apt-get install asciidoc xmlto docbook2x

　　當你安裝好全部的必要依賴，你能夠繼續從幾個地方來取得最新發布版本的 tar 包。 你能夠從 Kernel.org 網站獲取，網址爲 https://www.kernel.org/pub/software/scm/git，或從 GitHub 網站上的鏡像來得到，網址爲 https://github.com/git/git/releases。 一般在 GitHub 上的是最新版本，但 kernel.org 上包含有文件下載簽名，若是你想驗證下載正確性的話會用到。

　　接着，編譯並安裝：

$ tar -zxf git-2.0.0.tar.gz
$ cd git-2.0.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info

　　完成後，你可使用 Git 來獲取 Git 的升級：

$ git clone git://git.kernel.org/pub/scm/git/git.git

三、初次運行Git前的配置

　　每臺計算機上只須要配置一次，程序升級時會保留配置信息。 你能夠在任什麼時候候再次經過運行命令來修改它們。

　　Git 自帶一個 git config 的工具來幫助設置控制 Git 外觀和行爲的配置變量。

（1）配置變量存儲的三個不一樣的位置

　　1）/etc/gitconfig 文件: 包含系統上每個用戶及他們倉庫的通用配置。 若是使用帶有 --system 選項的 git config 時，它會今後文件讀寫配置變量。

　　2）~/.gitconfig 或 ~/.config/git/config 文件：只針對當前用戶。 能夠傳遞 --global 選項讓 Git 讀寫此文件。

　　3）當前使用倉庫的 Git 目錄中的 config 文件（就是 .git/config）：針對該倉庫。

注意：

　　每個級別覆蓋上一級別的配置，因此 .git/config 的配置變量會覆蓋 /etc/gitconfig 中的配置變量。

　　在 Windows 系統中，Git 會查找 $HOME 目錄下（通常狀況下是 C:\Users\$USER）的 .gitconfig文件。 Git 一樣也會尋找 /etc/gitconfig 文件，但只限於 MSys 的根目錄下，即安裝 Git 時所選的目標位置。

（2）用戶信息配置

　　當安裝完 Git 應該作的第一件事就是設置你的用戶名稱與郵件地址。 這樣作很重要，由於每個 Git 的提交都會使用這些信息，而且它會寫入到你的每一次提交中，不可更改：

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

　　再次強調，若是使用了 --global 選項，那麼該命令只須要運行一次，由於以後不管你在該系統上作任何事情， Git 都會使用那些信息。 當你想針對特定項目使用不一樣的用戶名稱與郵件地址時，能夠在那個項目目錄下運行沒有 --global 選項的命令來配置。

　　不少 GUI 工具都會在第一次運行時幫助你配置這些信息。

（3）配置文本編輯器

　　用戶信息設置完畢後，你能夠配置默認文本編輯器了，當 Git 須要你輸入信息時會調用它。 若是未配置，Git 會使用操做系統默認的文本編輯器，一般是 Vim。 若是你想使用不一樣的文本編輯器，例如 Emacs，能夠這樣作：

$ git config --global core.editor emacs

　　注意：Vim 和 Emacs 是像 Linux 與 Mac 等基於 Unix 的系統上開發者常用的流行的文本編輯器。 若是你對這些編輯器都不是很瞭解或者你使用的是 Windows 系統，那麼可能須要搜索如何在 Git 中配置你最經常使用的編輯器。 若是你不設置編輯器而且不知道 Vim 或 Emacs 是什麼，當它們運行起來後你可能會被弄糊塗、不知所措。

（4）檢查配置信息

　　若是想要檢查你的配置，可使用 git config --list 命令來列出全部 Git 當時能找到的配置。

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

　　你可能會看到重複的變量名，由於 Git 會從不一樣的文件中讀取同一個配置（例如：/etc/gitconfig 與 ~/.gitconfig）。 這種狀況下，Git 會使用它找到的每個變量的最後一個配置。

　　你能夠經過輸入 git config <key>： 來檢查 Git 的某一項配置

$ git config user.name
Doe Huang

四、獲取幫助

　　若你使用 Git 時須要獲取幫助，有三種方法能夠找到 Git 命令的使用手冊：

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

　　例如，要想得到 config 命令的手冊，執行

$ git help config

　　這些命令很棒，由於你隨時隨地可使用而無需聯網。 若是你以爲手冊或者本書的內容還不夠用，你能夠嘗試在 Freenode IRC 服務器（ irc.freenode.net ）的 #git 或 #github 頻道尋求幫助。 這些頻道常常有上百人在線，他們都精通 Git 而且樂於助人。

4、Git基礎

一、獲取Git倉庫

　　有兩種取得 Git 項目倉庫的方法。 第一種是在現有項目或目錄下導入全部文件到 Git 中； 第二種是從一個服務器克隆一個現有的 Git 倉庫。

（1）從現有目錄中初始化倉庫

　　若是你打算使用 Git 來對現有的項目進行管理，你只須要進入該項目目錄並輸入：

$ git init

　　若是是windows系統能夠在建立的項目的文件夾裏面右鍵點擊 Gir Bash Here 把git運行起來。

　　該命令將建立一個名爲 .git 的子目錄，這個子目錄含有你初始化的 Git 倉庫中全部的必須文件，這些文件是 Git 倉庫的骨幹。 可是，在這個時候，咱們僅僅是作了一個初始化的操做，你的項目裏的文件尚未被跟蹤。 (參見 Git 內部原理 來了解更多關於到底 .git 文件夾中包含了哪些文件的信息。)

　　若是你是在一個已經存在文件的文件夾（而不是空文件夾）中初始化 Git 倉庫來進行版本控制的話，你應該開始跟蹤這些文件並提交。 你可經過 git add 命令來實現對指定文件的跟蹤，而後執行 git commit提交：

（2）克隆現有倉庫

　　若是你想得到一份已經存在了的 Git 倉庫的拷貝，好比說，你想爲某個開源項目貢獻本身的一份力，這時就要用到 git clone 命令。

　　Git 區別於其它版本控制系統的一個重要特性，Git 克隆的是該 Git 倉庫服務器上的幾乎全部數據，而不是僅僅複製完成你的工做所須要文件。 當你執行 git clone 命令的時候，默認配置下遠程 Git 倉庫中的每個文件的每個版本都將被拉取下來。 事實上，若是你的服務器的磁盤壞掉了，你一般可使用任何一個克隆下來的用戶端來重建服務器上的倉庫（雖然可能會丟失某些服務器端的掛鉤設置，可是全部版本的數據仍在，詳見 在服務器上搭建 Git ）。

　　克隆倉庫的命令格式是 git clone [url] 。 好比，要克隆 Git 的可連接庫 libgit2，能夠用下面的命令：

$ git clone https://github.com/libgit2/libgit2

　　這會在當前目錄下建立一個名爲 「libgit2」 的目錄，並在這個目錄下初始化一個 .git 文件夾，從遠程倉庫拉取下全部數據放入 .git 文件夾，而後從中讀取最新版本的文件的拷貝。 若是你進入到這個新建的 libgit2 文件夾，你會發現全部的項目文件已經在裏面了。

　　若是你想在克隆遠程倉庫的時候，自定義本地倉庫的名字，你可使用以下命令：

$ git clone https://github.com/libgit2/libgit2 mylibgit

　　Git 支持多種數據傳輸協議。 上面的例子使用的是 https:// 協議，不過你也可使用 git:// 協議或者使用 SSH 傳輸協議，好比 user@server:path/to/repo.git 。 在服務器上搭建 Git 將會介紹全部這些協議在服務器端如何配置使用，以及各類方式之間的利弊。

二、記錄每次更新到倉庫

　　手上有了一個真實項目的 Git 倉庫，並從這個倉庫中取出了全部文件的工做拷貝。 接下來，對這些文件作些修改，在完成了一個階段的目標以後，提交本次更新到倉庫。

（1）文件狀態分類和變化週期

　　工做目錄下的每個文件都不外乎這兩種狀態：已跟蹤或未跟蹤。 已跟蹤的文件是指那些被歸入了版本控制的文件，在上一次快照中有它們的記錄，在工做一段時間後，它們的狀態可能處於未修改，已修改或已放入暫存區。 工做目錄中除已跟蹤文件之外的全部其它文件都屬於未跟蹤文件，它們既不存在於上次快照的記錄中，也沒有放入暫存區。 初次克隆某個倉庫的時候，工做目錄中的全部文件都屬於已跟蹤文件，並處於未修改狀態。

　　編輯過某些文件以後，因爲自上次提交後你對它們作了修改，Git 將它們標記爲已修改文件。 咱們逐步將這些修改過的文件放入暫存區，而後提交全部暫存了的修改，如此反覆。因此使用 Git 時文件的生命週期以下：

　　

（2）檢查當前文件狀態

 　　要查看哪些文件處於什麼狀態，能夠用 git status 命令。 若是在克隆倉庫後當即使用此命令，會看到相似這樣的輸出：

$ git init
Initialized empty Git repository in /Users/.../s9alipay/.git/
$ git status
On branch master
nothing to commit, working directory clean

　　這說明你如今的工做目錄至關乾淨。換句話說，全部已跟蹤文件在上次提交後都未被更改過。 此外，上面的信息還代表，當前目錄下沒有出現任何處於未跟蹤狀態的新文件，不然 Git 會在這裏列出來。 最後，該命令還顯示了當前所在分支，並告訴你這個分支同遠程服務器上對應的分支沒有偏離。 如今，分支名是 「master」,這是默認的分支名。 在 Git 分支 有詳細討論分支和引用。

　　若是在項目下建立一個新的 README 文件。 若是以前並不存在這個文件，使用 git status命令，將看到一個新的未跟蹤文件：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	.idea/workspace.xml
	README.MD
	alipay/__pycache__/
	app01/__pycache__/
	app01/migrations/__pycache__/
	utils/__pycache__/

nothing added to commit but untracked files present (use "git add" to track)

　　在狀態報告中能夠看到新建的 README 文件出如今 Untracked files 下面。 未跟蹤的文件意味着 Git 在以前的快照（提交）中沒有這些文件；Git 不會自動將之歸入跟蹤範圍，除非你明明白白地告訴它「我須要跟蹤該文件」， 這樣的處理讓你沒必要擔憂將生成的二進制文件或其它不想被跟蹤的文件包含進來。 不過如今的例子中，咱們確實想要跟蹤管理 README 這個文件。

（3）跟蹤新文件

　　使用命令 git add 開始跟蹤一個文件。

$ git add README.MD 

　　注意：git add 命令使用文件或目錄的路徑做爲參數；若是參數是目錄的路徑，該命令將遞歸地跟蹤該目錄下的全部文件。　　

　　此時再運行 git status 命令，會看到 README 文件已被跟蹤，並處於暫存狀態：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   README.MD

　　在 Changes to be committed 這行下面的，就說明是已暫存狀態。 若是此時提交，那麼該文件此時此刻的版本將被留存在歷史記錄中。

（4）暫存已修改文件

　　如今咱們來修改一個已被跟蹤的文件。 若是你修改了一個名爲  app01/views.py 的已被跟蹤的文件，而後運行 git status 命令，會看到下面內容：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   README.MD

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   app01/tests.py
	modified:   app01/views.py

　　出如今 Changes not staged for commit 這行下面，說明已跟蹤文件的內容發生了變化，但尚未放到暫存區。 要暫存此次更新，須要運行 git add 命令。

　　git add 是個多功能命令：能夠用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區，還能用於合併時把有衝突的文件標記爲已解決狀態等。 將這個命令理解爲「添加內容到下一次提交中」而不是「將一個文件添加到項目中」要更加合適。 如今讓咱們運行 git add 將"app01/views.py"放到暫存區，而後再看看 git status 的輸出：

$ git add app01/views.py 
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   README.MD
	modified:   app01/views.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   app01/tests.py

　　如今兩個文件都已暫存，下次提交時就會一併記錄到倉庫。

　　注意：若是在提交前，又進行了修改，文件將同時出如今暫存區和非暫存區。 這怎麼可能呢？ 好吧，實際上 Git 只不過暫存了你運行 git add 命令時的版本， 若是你如今提交，文件版本是你最後一次運行 git add 命令時的那個版本，而不是你運行 git commit 時，在工做目錄中的當前版本。 因此，運行了 git add 以後又做了修訂的文件，須要從新運行 git add 把最新版本從新暫存起來：

（5）狀態簡覽

　　git status 命令的輸出十分詳細，但其用語有些繁瑣。 若是你使用 git status -s 命令或 git status --short 命令，你將獲得一種更爲緊湊的格式輸出。 運行 git status -s ，狀態報告輸出以下：

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

　　新添加的未跟蹤文件前面有 ?? 標記，新添加到暫存區中的文件前面有 A 標記，修改過的文件前面有 M 標記。

　　你可能注意到了 M 有兩個能夠出現的位置，出如今右邊的 M 表示該文件被修改了可是還沒放入暫存區，出如今靠左邊的 M 表示該文件被修改了並放入了暫存區。 例如，上面的狀態報告顯示： README 文件在工做區被修改了可是尚未將修改後的文件放入暫存區,lib/simplegit.rb 文件被修改了並將修改後的文件放入了暫存區。 而 Rakefile 在工做區被修改並提交到暫存區後又在工做區中被修改了，因此在暫存區和工做區都有該文件被修改了的記錄。

（6）忽略文件

　　通常咱們總會有些文件無需歸入 Git 的管理，也不但願它們總出如今未跟蹤文件列表。 一般都是些自動生成的文件，好比日誌文件，或者編譯過程當中建立的臨時文件等。 在這種狀況下，咱們能夠建立一個名爲 .gitignore 的文件，列出要忽略的文件模式。 

（7）查看已暫存和未暫存的修改

　　想知道具體修改了什麼地方，能夠用  git diff 命令。

　　要查看 還沒有暫存的文件更新了哪些部分，不加參數直接輸入  git diff：

$ git diff
diff --git a/app01/tests.py b/app01/tests.py
index 7ce503c..1636138 100644
--- a/app01/tests.py
+++ b/app01/tests.py
@@ -1,3 +1,10 @@
 from django.test import TestCase
 
 # Create your tests here.
+
+def func(n):
+    n += 1
+    print(n)
+
+func(3)

　　此命令比較的是工做目錄中當前文件和暫存區域快照之間的差別， 也就是修改以後尚未暫存起來的變化內容。

　　若要查看已暫存的將要添加到下次提交裏的內容，能夠用 git diff --cached 命令（--staged 和 --cached 是同義詞）。（Git 1.6.1 及更高版本還容許使用 git diff --staged，效果是相同的，但更好記些。）

$ git diff --staged
diff --git a/README.MD b/README.MD
new file mode 100644
index 0000000..ef195df
--- /dev/null
+++ b/README.MD
@@ -0,0 +1,44 @@
+# alipay(服務端支付寶)

　　請注意：git diff 自己只顯示還沒有暫存的改動，而不是自上次提交以來所作的全部改動。 因此有時候你一會兒暫存了全部更新過的文件後，運行 git diff 後卻什麼也沒有，就是這個緣由。

（8）提交更新

　　當暫存區域已經準備穩當，就能夠提交了 。在此以前，請必定要確認還有什麼修改過的或新建的文件尚未 git add 過，不然提交的時候不會記錄這些還沒暫存起來的變化。 這些修改過的文件只保留在本地磁盤。 因此，每次準備提交前，先用 git status 看下，是否是都已暫存起來了， 而後再運行提交命令 git commit：

$ git commit

　　這種方式會啓動文本編輯器以便輸入本次提交的說明。 (默認會啓用 shell 的環境變量 $EDITOR 所指定的軟件，通常都是 vim 或 emacs。固然也能夠按照 起步 介紹的方式，使用 git config --global core.editor 命令設定你喜歡的編輯軟件。）

　　編輯器會顯示相似下面的文本信息（本例選用 Vim 的屏顯方式展現）：

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#       new file:   README.MD
#       modified:   app01/views.py
~

　　默認的提交消息包含最後一次運行 git status 的輸出，放在註釋行裏，另外開頭還有一空行，供你輸入提交說明。

　　退出編輯器時，Git 會丟掉註釋行，用你輸入提交附帶信息生成一次提交。

$ git commit
[master ad9cae3] git test
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 README.MD

　　另外，你也能夠在 commit 命令後添加 -m 選項，將提交信息與命令放在同一行，以下所示：

$ git commit -m "git test"

（9）提交跳過使用暫存區域

　　Git 提供了一個跳過使用暫存區域的方式， 只要在提交的時候，給 git commit 加上 -a 選項，Git 就會自動把全部已經跟蹤過的文件暫存起來一併提交，從而跳過 git add 步驟：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md
no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

　　這樣提交以前再也不須要 git add 文件「CONTRIBUTING.md」了。

（10）移除文件

　　要從 Git 中移除某個文件，就必需要從已跟蹤文件清單中移除（確切地說，是從暫存區域移除），而後提交。 能夠用 git rm 命令完成此項工做，並連帶從工做目錄中刪除指定的文件，這樣之後就不會出如今未跟蹤文件清單中了。

　　若是隻是簡單地從工做目錄中手工刪除文件，運行 git status 時就會在 「Changes not staged for commit」 部分（也就是 未暫存清單）看到：

$ rm app01/tests.py 
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    app01/tests.py

　　而後再運行 git rm 記錄這次移除文件的操做：

$ git rm app01/tests.py
rm 'app01/tests.py'
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    app01/tests.py

　　下一次提交時，該文件就再也不歸入版本管理了。 若是刪除以前修改過而且已經放到暫存區域的話，則必需要用強制刪除選項 -f（譯註：即 force 的首字母）。 這是一種安全特性，用於防止誤刪尚未添加到快照的數據，這樣的數據不能被 Git 恢復。