2.2 記錄每次更新到倉庫 · Pro Git 第二版（中文版）

# 記錄每次更新到倉庫現在我們手上有了一個真實項目的 Git 倉庫，并從這個倉庫中取出了所有文件的工作拷貝。接下來，對這些文件做些修改，在完成了一個階段的目標之后，提交本次更新到倉庫。請記住，你工作目錄下的每一個文件都不外乎這兩種狀態：已跟蹤或未跟蹤。已跟蹤的文件是指那些被納入了版本控制的文件，在上一次快照中有它們的記錄，在工作一段時間后，它們的狀態可能處于未修改，已修改或已放入暫存區。工作目錄中除已跟蹤文件以外的所有其它文件都屬于未跟蹤文件，它們既不存在于上次快照的記錄中，也沒有放入暫存區。初次克隆某個倉庫的時候，工作目錄中的所有文件都屬于已跟蹤文件，并處于未修改狀態。編輯過某些文件之后，由于自上次提交后你對它們做了修改，Git 將它們標記為已修改文件。我們逐步將這些修改過的文件放入暫存區，然后提交所有暫存了的修改，如此反復。所以使用 Git 時文件的生命周期如下： ![Git 下文件生命周期圖。](https://box.kancloud.cn/2015-10-12_561bcb568ace5.png) Figure 2-1. 文件的狀態變化周期 ## 檢查當前文件狀態要查看哪些文件處于什么狀態，可以用 `git status` 命令。如果在克隆倉庫后立即使用此命令，會看到類似這樣的輸出： ~~~ $ git status On branch master nothing to commit, working directory clean ~~~ 這說明你現在的工作目錄相當干凈。換句話說，所有已跟蹤文件在上次提交后都未被更改過。此外，上面的信息還表明，當前目錄下沒有出現任何處于未跟蹤狀態的新文件，否則 Git 會在這里列出來。最后，該命令還顯示了當前所在分支，并告訴你這個分支同遠程服務器上對應的分支沒有偏離。現在，分支名是 “master”,這是默認的分支名。我們在 [Chapter?3](#) 會詳細討論分支和引用。現在，讓我們在項目下創建一個新的 README 文件。如果之前并不存在這個文件，使用 `git status` 命令，你將看到一個新的未跟蹤文件： ~~~ $ echo 'My Project' > README $ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) README nothing added to commit but untracked files present (use "git add" to track) ~~~ 在狀態報告中可以看到新建的 README 文件出現在 `Untracked files` 下面。未跟蹤的文件意味著 Git 在之前的快照（提交）中沒有這些文件；Git 不會自動將之納入跟蹤范圍，除非你明明白白地告訴它“我需要跟蹤該文件”，這樣的處理讓你不必擔心將生成的二進制文件或其它不想被跟蹤的文件包含進來。不過現在的例子中，我們確實想要跟蹤管理 README 這個文件。 ## 跟蹤新文件使用命令 `git add` 開始跟蹤一個文件。所以，要跟蹤 README 文件，運行： ~~~ $ git add README ~~~ 此時再運行 `git status` 命令，會看到 README 文件已被跟蹤，并處于暫存狀態： ~~~ $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README ~~~ 只要在 `Changes to be committed` 這行下面的，就說明是已暫存狀態。如果此時提交，那么該文件此時此刻的版本將被留存在歷史記錄中。你可能會想起之前我們使用 `git init` 后就運行了 `git add (files)` 命令，開始跟蹤當前目錄下的文件。`git add` 命令使用文件或目錄的路徑作為參數；如果參數是目錄的路徑，該命令將遞歸地跟蹤該目錄下的所有文件。 ## 暫存已修改文件現在我們來修改一個已被跟蹤的文件。如果你修改了一個名為 `CONTRIBUTING.md` 的已被跟蹤的文件，然后運行 `git status` 命令，會看到下面內容： ~~~ $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README 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 ~~~ 文件 `CONTRIBUTING.md` 出現在 `Changes not staged for commit` 這行下面，說明已跟蹤文件的內容發生了變化，但還沒有放到暫存區。要暫存這次更新，需要運行 `git add` 命令。這是個多功能命令：可以用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區，還能用于合并時把有沖突的文件標記為已解決狀態等。將這個命令理解為“添加內容到下一次提交中”而不是“將一個文件添加到項目中”要更加合適。現在讓我們運行 `git add` 將"CONTRIBUTING.md"放到暫存區，然后再看看 `git status` 的輸出： ~~~ $ git add CONTRIBUTING.md $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: CONTRIBUTING.md ~~~ 現在兩個文件都已暫存，下次提交時就會一并記錄到倉庫。假設此時，你想要在 `CONTRIBUTING.md` 里再加條注釋，重新編輯存盤后，準備好提交。不過且慢，再運行 `git status` 看看： ~~~ $ vim CONTRIBUTING.md $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: CONTRIBUTING.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: CONTRIBUTING.md ~~~ 怎么回事？現在 `CONTRIBUTING.md` 文件同時出現在暫存區和非暫存區。這怎么可能呢？好吧，實際上 Git 只不過暫存了你運行 `git add` 命令時的版本，如果你現在提交，`CONTRIBUTING.md` 的版本是你最后一次運行 `git add` 命令時的那個版本，而不是你運行 `git commit` 時，在工作目錄中的當前版本。所以，運行了 `git add` 之后又作了修訂的文件，需要重新運行 `git add` 把最新版本重新暫存起來： ~~~ $ git add CONTRIBUTING.md $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: CONTRIBUTING.md ~~~ ## 狀態簡覽 `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` 在工作區被修改并提交到暫存區后又在工作區中被修改了，所以在暫存區和工作區都有該文件被修改了的記錄。 ## 忽略文件一般我們總會有些文件無需納入 Git 的管理，也不希望它們總出現在未跟蹤文件列表。通常都是些自動生成的文件，比如日志文件，或者編譯過程中創建的臨時文件等。在這種情況下，我們可以創建一個名為 `.gitignore` 的文件，列出要忽略的文件模式。來看一個實際的例子： ~~~ $ cat .gitignore *.[oa] *~ ~~~ 第一行告訴 Git 忽略所有以 `.o` 或 `.a` 結尾的文件。一般這類對象文件和存檔文件都是編譯過程中出現的。第二行告訴 Git 忽略所有以波浪符（~）結尾的文件，許多文本編輯軟件（比如 Emacs）都用這樣的文件名保存副本。此外，你可能還需要忽略 log，tmp 或者 pid 目錄，以及自動生成的文檔等等。要養成一開始就設置好 .gitignore 文件的習慣，以免將來誤提交這類無用的文件。文件 `.gitignore` 的格式規范如下： - 所有空行或者以 `＃` 開頭的行都會被 Git 忽略。 - 可以使用標準的 glob 模式匹配。 - 匹配模式可以以（`/`）開頭防止遞歸。 - 匹配模式可以以（`/`）結尾指定目錄。 - 要忽略指定模式以外的文件或目錄，可以在模式前加上驚嘆號（`!`）取反。所謂的 glob 模式是指 shell 所使用的簡化了的正則表達式。星號（`*`）匹配零個或多個任意字符；`[abc]` 匹配任何一個列在方括號中的字符（這個例子要么匹配一個 a，要么匹配一個 b，要么匹配一個 c）；問號（`?`）只匹配一個任意字符；如果在方括號中使用短劃線分隔兩個字符，表示所有在這兩個字符范圍內的都可以匹配（比如 `[0-9]` 表示匹配所有 0 到 9 的數字）。使用兩個星號（`*`) 表示匹配任意中間目錄，比如`a/**/z` 可以匹配 `a/z`, `a/b/z` 或 `a/b/c/z`等。我們再看一個 .gitignore 文件的例子： ~~~ # no .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the TODO file in the current directory, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .pdf files in the doc/ directory doc/**/*.pdf ~~~ GitHub 有一個十分詳細的針對數十種項目及語言的 `.gitignore` 文件列表，你可以在 [*https://github.com/github/gitignore*](https://github.com/github/gitignore) 找到它. ## 查看已暫存和未暫存的修改如果 `git status` 命令的輸出對于你來說過于模糊，你想知道具體修改了什么地方，可以用 `git diff` 命令。稍后我們會詳細介紹 `git diff`，你可能通常會用它來回答這兩個問題：當前做的哪些更新還沒有暫存？有哪些更新已經暫存起來準備好了下次提交？盡管 `git status` 已經通過在相應欄下列出文件名的方式回答了這個問題，`git diff` 將通過文件補丁的格式顯示具體哪些行發生了改變。假如再次修改 README 文件后暫存，然后編輯 `CONTRIBUTING.md` 文件后先不暫存，運行 `status` 命令將會看到： ~~~ $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: README 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 ~~~ 要查看尚未暫存的文件更新了哪些部分，不加參數直接輸入 `git diff`： ~~~ $ git diff diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8ebb991..643e24f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -65,7 +65,8 @@ branch directly, things can get messy. Please include a nice description of your changes when you submit your PR; if we have to read the whole diff to figure out why you're contributing in the first place, you're less likely to get feedback and have your change -merged in. +merged in. Also, split your changes into comprehensive chunks if your patch is +longer than a dozen lines. If you are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR title that it's ~~~ 此命令比較的是工作目錄中當前文件和暫存區域快照之間的差異，也就是修改之后還沒有暫存起來的變化內容。若要查看已暫存的將要添加到下次提交里的內容，可以用 `git diff --cached` 命令。（Git 1.6.1 及更高版本還允許使用 `git diff --staged`，效果是相同的，但更好記些。） ~~~ $ git diff --staged diff --git a/README b/README new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/README @@ -0,0 +1 @@ +My Project ~~~ 請注意，git diff 本身只顯示尚未暫存的改動，而不是自上次提交以來所做的所有改動。所以有時候你一下子暫存了所有更新過的文件后，運行 `git diff` 后卻什么也沒有，就是這個原因。像之前說的，暫存 `CONTRIBUTING.md` 后再編輯，運行 `git status` 會看到暫存前后的兩個版本。如果我們的環境（終端輸出）看起來如下： ~~~ $ git add CONTRIBUTING.md $ echo '# test line' >> CONTRIBUTING.md $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: CONTRIBUTING.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: CONTRIBUTING.md ~~~ 現在運行 `git diff` 看暫存前后的變化： ~~~ $ git diff diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 643e24f..87f08c8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -119,3 +119,4 @@ at the ## Starter Projects See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md). +# test line ~~~ 然后用 `git diff --cached` 查看已經暫存起來的變化：（--staged 和 --cached 是同義詞） ~~~ $ git diff --cached diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8ebb991..643e24f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -65,7 +65,8 @@ branch directly, things can get messy. Please include a nice description of your changes when you submit your PR; if we have to read the whole diff to figure out why you're contributing in the first place, you're less likely to get feedback and have your change -merged in. +merged in. Also, split your changes into comprehensive chunks if your patch is +longer than a dozen lines. If you are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR title that it's ~~~ > ### Git Diff 的插件版本 > 在本書中，我們使用 `git diff` 來分析文件差異。但是，如果你喜歡通過圖形化的方式或其它格式輸出方式的話，可以使用 `git difftool` 命令來用 Araxis ，emerge 或 vimdiff 等軟件輸出 diff 分析結果。使用 `git difftool --tool-help` 命令來看你的系統支持哪些 Git Diff 插件。 ## 提交更新現在的暫存區域已經準備妥當可以提交了。在此之前，請一定要確認還有什么修改過的或新建的文件還沒有 `git add` 過，否則提交的時候不會記錄這些還沒暫存起來的變化。這些修改過的文件只保留在本地磁盤。所以，每次準備提交前，先用 `git status` 看下，是不是都已暫存起來了，然后再運行提交命令 `git commit`： ~~~ $ git commit ~~~ 這種方式會啟動文本編輯器以便輸入本次提交的說明。(默認會啟用 shell 的環境變量 `$EDITOR` 所指定的軟件，一般都是 vim 或 emacs。當然也可以按照 [Chapter?1](#) 介紹的方式，使用 `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 # Changes to be committed: # new file: README # modified: CONTRIBUTING.md # ~ ~ ~ ".git/COMMIT_EDITMSG" 9L, 283C ~~~ 可以看到，默認的提交消息包含最后一次運行 `git status` 的輸出，放在注釋行里，另外開頭還有一空行，供你輸入提交說明。你完全可以去掉這些注釋行，不過留著也沒關系，多少能幫你回想起這次更新的內容有哪些。(如果想要更詳細的對修改了哪些內容的提示，可以用 `-v` 選項，這會將你所做的改變的 diff 輸出放到編輯器中從而使你知道本次提交具體做了哪些修改。）退出編輯器時，Git 會丟掉注釋行，用你輸入提交附帶信息生成一次提交。另外，你也可以在 `commit` 命令后添加 `-m` 選項，將提交信息與命令放在同一行，如下所示： ~~~ $ git commit -m "Story 182: Fix benchmarks for speed" [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 2 insertions(+) create mode 100644 README ~~~ 好，現在你已經創建了第一個提交！可以看到，提交后它會告訴你，當前是在哪個分支（`master`）提交的，本次提交的完整 SHA-1 校驗和是什么（`463dc4f`），以及在本次提交中，有多少文件修訂過，多少行添加和刪改過。請記住，提交時記錄的是放在暫存區域的快照。任何還未暫存的仍然保持已修改狀態，可以在下次提交時納入版本管理。每一次運行提交操作，都是對你項目作一次快照，以后可以回到這個狀態，或者進行比較。 ## 跳過使用暫存區域盡管使用暫存區域的方式可以精心準備要提交的細節，但有時候這么做略顯繁瑣。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”了。 ## 移除文件要從 Git 中移除某個文件，就必須要從已跟蹤文件清單中移除（確切地說，是從暫存區域移除），然后提交。可以用 `git rm` 命令完成此項工作，并連帶從工作目錄中刪除指定的文件，這樣以后就不會出現在未跟蹤文件清單中了。如果只是簡單地從工作目錄中手工刪除文件，運行 `git status` 時就會在 “Changes not staged for commit” 部分（也就是 *未暫存清單*）看到： ~~~ $ rm PROJECTS.md $ git status On branch master Your branch is up-to-date with 'origin/master'. 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: PROJECTS.md no changes added to commit (use "git add" and/or "git commit -a") ~~~ 然后再運行 `git rm` 記錄此次移除文件的操作： ~~~ $ git rm PROJECTS.md rm 'PROJECTS.md' $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: PROJECTS.md ~~~ 下一次提交時，該文件就不再納入版本管理了。如果刪除之前修改過并且已經放到暫存區域的話，則必須要用強制刪除選項 `-f`（譯注：即 force 的首字母）。這是一種安全特性，用于防止誤刪還沒有添加到快照的數據，這樣的數據不能被 Git 恢復。另外一種情況是，我們想把文件從 Git 倉庫中刪除（亦即從暫存區域移除），但仍然希望保留在當前工作目錄中。換句話說，你想讓文件保留在磁盤，但是并不想讓 Git 繼續跟蹤。當你忘記添加 `.gitignore` 文件，不小心把一個很大的日志文件或一堆 `.a` 這樣的編譯生成文件添加到暫存區時，這一做法尤其有用。為達到這一目的，使用 `--cached` 選項： ~~~ $ git rm --cached README ~~~ `git rm` 命令后面可以列出文件或者目錄的名字，也可以使用 `glob` 模式。比方說： ~~~ $ git rm log/\*.log ~~~ 注意到星號 `*` 之前的反斜杠 `\`，因為 Git 有它自己的文件模式擴展匹配方式，所以我們不用 shell 來幫忙展開。此命令刪除 `log/` 目錄下擴展名為 `.log` 的所有文件。類似的比如： ~~~ $ git rm \*~ ~~~ 該命令為刪除以 `~` 結尾的所有文件。 ## 移動文件不像其它的 VCS 系統，Git 并不顯式跟蹤文件移動操作。如果在 Git 中重命名了某個文件，倉庫中存儲的元數據并不會體現出這是一次改名操作。不過 Git 非常聰明，它會推斷出究竟發生了什么，至于具體是如何做到的，我們稍后再談。既然如此，當你看到 Git 的 `mv` 命令時一定會困惑不已。要在 Git 中對文件改名，可以這么做： ~~~ $ git mv file_from file_to ~~~ 它會恰如預期般正常工作。實際上，即便此時查看狀態信息，也會明白無誤地看到關于重命名操作的說明： ~~~ $ git mv README.md README $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README.md -> README ~~~ 其實，運行 `git mv` 就相當于運行了下面三條命令： ~~~ $ mv README.md README $ git rm README.md $ git add README ~~~ 如此分開操作，Git 也會意識到這是一次改名，所以不管何種方式結果都一樣。兩者唯一的區別是，`mv` 是一條命令而另一種方式需要三條命令，直接用 `git mv` 輕便得多。不過有時候用其他工具批處理改名的話，要記得在提交前刪除老的文件名，再添加新的文件名。