2.2 Git 基礎 - 記錄每次更新到倉庫

記錄每次更新到倉庫

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

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

編輯過某些文件之後，由於自上次提交後你對它們做了修改，Git 將它們標記爲已修改文件。我們逐步將這些修改過的文件放入暫存區，然後提交所有暫存了的修改，如此反覆。所以使用 Git 時文件的生命週期如下：

Figure 8. 文件的狀態變化週期

檢查當前文件狀態

要查看哪些文件處於什麼狀態，可以用 git status 命令。如果在克隆倉庫後立即使用此命令，會看到類似這樣的輸出：

$ git status
On branch master
nothing to commit, working directory clean

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

現在，讓我們在項目下創建一個新的 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

Tip	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

Note	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。當然也可以按照起步介紹的方式，使用 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 輕便得多。不過有時候用其他工具批處理改名的話，要記得在提交前刪除老的文件名，再添加新的文件名。

Git版本管理系統學習之Git 基礎——記錄每次更新到倉庫

2.2 Git 基礎 - 記錄每次更新到倉庫

記錄每次更新到倉庫

檢查當前文件狀態

跟蹤新文件

暫存已修改文件

狀態簡覽

忽略文件

查看已暫存和未暫存的修改

提交更新

跳過使用暫存區域

移除文件

移動文件

釘釘打卡速度慢

Nginx R31 doc 官方文檔-01-nginx 如何安裝

Qt/C++音視頻開發74-合併標籤圖形/生成yolo運算結果圖形/文字和圖形合併成一個/水印濾鏡

挑戰程序設計競賽 2.2章習題 POJ - 3617 Best Cow Line 貪心

字節面試：MySQL什麼時候鎖表？如何防止鎖表？

.NET8連接SQL SERVER 2008 R2 報：證書鏈是由不受信任的頒發機構頒發的

golang開發環境搭建(win10)

python計算機視覺學習筆記——PIL庫的用法

Golang初學：獲取程序內存使用情況，std runtime

Python面向對象（三）：異常、模塊和包、文件、eval函數

Python基礎（二）：多文件項目、註釋、算數運算符、程序執行原理和變量的基本使用

Python基礎之Linux基礎（五）：常用 Linux 命令的基本使用

Python基礎之Linux基礎（十）：系統信息相關命令

Python基礎之Linux基礎（七）：文件和目錄常用命令

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結