這篇文章介紹下版本控制器。

Git是什么

Git是一種版本控制器，幫助我們管理一個文件的各種版本，Git幾乎可以管理所有的文件，但是對于程序員來說，最常見的就是管理源文件。

• 注意：Git作為版本控制器，它并不會給你保存所有的版本的文件，它只會告訴你改動的地方，對于文本文件是這樣；對于視頻、音頻這些二進制文件，它只能告訴你它們的改動前后的大小的變化。

Git的安裝

1. centos下：

   #更新軟件包列表
   sudo yum update -y#安裝git
   sudo yum install git -y#驗證安裝
   git --version
   

2. ubuntu下：

   #更新軟件包列表
   sudo apt-get update#安裝git
   sudo apt-get install git -y#驗證安裝
   git --version
   

3. windows下：

   • 前往官網安裝git.

   • 安裝后，本地會有Git Bash 和 Git GUI這兩個應用：

     • Git Bash：提供了一個類似于 Linux 的命令行界面，適合喜歡命令行操作的用戶。
     • Git GUI：為那些更傾向于圖形界面操作的用戶提供了一個可視化的工具。

   • Windows 的命令行（如 CMD 或 PowerShell）中能夠直接使用 git 指令，說明 Git 已經被正確安裝并且其路徑已經被添加到系統的環境變量中。這是 Git 安裝程序的默認行為。

     

Git的基本操作

建立本地倉庫

在 Git 中，本地倉庫指的是存儲在計算機上的一個文件夾，它包含了項目的所有文件以及這些文件的版本歷史記錄。每個 Git 倉庫（repository）都是一個獨立的單元，允許您進行版本控制、提交更改、查看歷史記錄等操作。即使沒有網絡連接，您也可以在本地倉庫中工作，并且在有需要時將更改推送到遠程倉庫。

1. 新建立一個本地倉庫：如果此時有一個沒有使用git進行版本控制的目錄，就可以初始化建立一個新的git倉庫

   #先進入該目錄
   cd /path/project#初始化本地倉庫
   git init
   

除此之外，還可以建立遠程倉庫后，再將其克隆到本地。

配置本地倉庫

配置本地倉庫，主要是配置用戶信息。Git 使用用戶名和郵箱來標記每次提交的作者信息。這些信息會嵌入到提交記錄中，并在推送至遠程倉庫時被共享。這樣就可以知道每個提交記錄的作者了。

1. 設置全局用戶信息：如果你希望所有的本地倉庫都使用相同相同的用戶名和郵箱信息，可以直接奢姿全局的用戶信息：

   git config --global user.name "Your Name"
   git config --global user.email "you@example.com"
   

   • -global 參數表示這些配置將應用于當前用戶的所有 Git 倉庫。

2. 可以通過以下指令查看當前的全局的用戶信息：

   git config --global --list
   

3. 設置局部（本地倉庫）的用戶信息：也可以僅設置局部的用戶信息。

   git config user.name "Your Name"
   git config user.email "you@example.com"
   

4. 可以通過以下指令查看當前倉庫的局部的用戶信息：

   git config --loacl --list
   

   

認識工作區、暫存區、版本庫的概念

1. 工作區：新建一個倉庫后會生成一個.git目錄，與這個.git目錄在同一個目錄及其子目錄的區域都叫工作區，我們未來開發就在這個區域，不包括.git。

   

2. 暫存區：暫存區是一個臨時存儲區域，用于存放即將作為下一次提交一部分的文件更改。它位于工作區和版本庫之間，充當一個緩沖區的角色。通過使用暫存區，您可以更精細地控制哪些更改會包含在下一個提交中。

   • 只有在暫存區的文件才會被提交，所以有了暫存區我們就可以多次提交。現在這個倉庫沒有添加文件到暫存區（Stage/index），所以該目錄沒有建立。

     

3. 版本庫：存儲所有文件歷史記錄的地方，支持分支管理和版本回滾。整個.git目錄我們將其稱之為版本庫，將文件添加到版本庫后，我們才能對其進行管理。

   

[!caution]

工作區的文件如果沒有添加到暫存區和版本庫是不能對其進行管理的。

三者的關系：

• 在創建 Git 版本庫時，Git 會為我們?動創建?個唯?的 master 分?，以及指向 master 的?個指

針叫 HEAD，這個我們后面再談。

添加文件

添加文件到暫存區

• 使用如下指令將文件添加到暫存區：

#添加部分文件
git add 文件1 文件2#添加所有新增或修改的文件
git add .

提交文件到版本庫

只添加了文件到暫存區，還不能管理它，必須將暫存區中的文件提交到版本庫。

git commit - m "描述信息"

• 描述信息是很重要的，合理的描述信息可以在日志中看到這次提交主要的修改內容，便于管理。

提交文件演示

1. 先在工作區創建一個文件file1.txt：

   

2. 我們可以使用以下命令，顯示工作目錄和暫存區的狀態：

   git status 
   

   該命令還會提示下一步的應該怎么做：

   

3. 將文件添加到暫存區：

   

4. 此時暫存區有內容了，我們可以查看一下.git目錄，看看它的變化：

   

   • 多了一個index文件，這就是傳說中的暫存區，如果我們繼續新建文件，然后將代碼添加到暫存區，該文件到大小會變大：

     

5. 提交文件到倉庫區：

   

理解.git目錄中的文件

HEAD指針與暫存區

.git目錄中有一些目錄和文件，在windwos下我們可以使用以下命令查看隱藏文件或目錄：

Get-ChildItem -Force 

• cd命令進入.git目錄：

  

• index就是我們的暫存區，前面已經說過了。

• HEAD指針指向的是當前的默認分支master的最新commit，我們可以打印出HEAD文件來看一下它里面的內容：

  

打印refs/heads/master的內容：

objects對象

這一連串的數字是什么呢？

在 Git 中，refs/heads/master（或更一般地 refs/heads/）指向的是某個分支的最新提交（即該分支的頭部）。這里的“值”實際上是一個 40 字符長的 SHA-1 哈希值，它唯一標識了一個具體的提交對象。

每一個提交的對象都會保存在.git的Object目錄中：

這個5e目錄中有一個文件就叫做69892b75b83d991b99f1c29a5ebfaba53ee0f0。

• objects是git存儲庫的核心組成部分，里面包含了各種對象，當我們git add時就會創建對象用來保存修改的內容。

• 對于refs/heads/master保存的commit ID，前2位是目錄名，后面的都是文件名。

• 我們可以使用以下指令來查看某個對象保存的內容，默認情況下是二進制，直接cat打印是亂碼。

  git cat-file -p <SHA-1>
  

  

前面一行有個tree，它后面也跟了一行哈希值。我們直接打印看看是什么內容：

tree 對象的主要作用是描述某個提交（commit）所對應的文件和目錄結構。

除了這個tree對象除了保存，提交的文件名，似乎前面還有個blob，blob對象后面也跟了一行哈希值，兩個文件兩個blob對象，我們猜測一下這應該是我們修改的內容：

blob對象用于存儲文件的內容。

所有我們大概清楚objects中是有不同的對象的：blob對象、tree對象。

那refs/heads/master中保存的是objects中的什么對象呢？我們可以使用下面指令來查某個對象的類型：

git cat-file -t <SHA-1>

HEAD就是我們前面談到的特殊引用，它指向當前分支的最新commit，它指向的文件其實保存的就是一個commit對象的SHA-1哈希值。

總結一下objects對象的類型及其創建時期：

• blob對象：
  • 作用：用于存儲文件的內容、每個文件版本的內容會被存儲為一個獨立的 blob 對象、文件名和目錄信息不包含在 blob 中，而是由 tree 對象管理。
  • 創建時期：運行 git add 時
• tree對象：
  • 作用：用于表示目錄結構、包含指向 blob 對象（文件）或其它 tree 對象（子目錄）的引用，以及對應的文件名或目錄名。
  • 創建時期：當運行 git commit 時，Git 會為當前的目錄結構創建一個 tree 對象，目錄結構沒變化，復用已有的tree對象。
• commit對象：
  • 作用：用于記錄項目的快照。
    包含以下信息：
    • 指向一個 tree 對象（描述提交時的目錄結構）。
    • 提交的元數據（如作者、提交者、日期、提交消息等）。
    • 指向父提交（parent commits），用于構建提交歷史。
  • 創建時期：運行 git commit 時，Git 會創建一個新的 commit 對象，每次提交都會創建一個commit對象即使內容沒有變化。
• Tag對象：
  • 作用：用于為特定的 commit 提供一個永久性的名稱或標簽。
  • 創建時期：當您運行 git tag <tag-name> 時，Git 會創建一個輕量級標簽。

[!caution]

如果當前提交是項目中的第一個提交（即初始提交），那么它沒有父提交。

添加文件–場景二

下面我們創建兩個文件，但是只將一個添加到暫存區，然后提交，順便打印當前的commit對象的內容，看看是否有父commit對象。

1. 在工作區新建兩個文件f1.txt、f2.txt：

   

2. 將f1.txt添加進暫存區并提交：

   

[!NOTE]

為什么這里只有 1 file changed呢？明明我們創建了兩個文件，因為commit只會提交git add后的文件，也就是位于暫存區的文件。

3. 此時我們再打印HEAD指針指向的commit對象的內容：

   

4. 我們驚奇的發現，此時的commit對象居然多了一行parent，我們打印它：

   

   • 這他喵不就是我們上次提交的commit對象嘛，所以驗證了指向父提交（parent commits），用于構建提交歷史。

修改文件

git比其他的版本控制器設計的優秀，正在于它跟蹤管理的是文件修改，而非文件本身，下面我們驗證一下，什么叫修改呢？凡是對文件到增刪改都叫修改。

1. 查看當前工作區的目錄結構：

   

2. 我們給file.txt新增一行aaaaa：

   

3. 將修改后的file.txt添加到暫存區并提交：

   

4. 我們可以查看file.txt到blob對象是保存的文件內容：

   

5. 這樣可能看不出來，我們繼續給file.txt文件增加一行內容，然后git add、git commit：

   

   • blob對象的確是保存的當前版本的文件的內容。

6. 我們可以通過以下命令來查看一下當前工作區文件與暫存區、版本庫中的最新一次提交的差異：

   #工作區與暫存區
   git diff [file]#工作區與版本庫
   git diff HEAD -- [file]
   

   

如果文件內容中包含了一些非標準的字符（如 和 ^@），Git 將其部分識別為二進制數據或特殊編碼格式，這個時候我們可以使用-a選項強轉。

這一行描述了差異的具體范圍：

• -1,4：表示舊版本從第 1 行開始，共 4 行。
• +1,4：表示新版本從第 1 行開始，共 4 行。
• 換句話說，Git 在比較兩版文件時，發現它們的前 3 行相同，只有第 4 行發生了變化。

版本回退

版本回退的基本操作

1. 查看提交歷史：

   git log --oneline
   

   

2. 使用 git reset：git reset 是最常用的回退命令之一，它允許您將 HEAD 指針移動到指定的提交，并可以選擇是否保留工作目錄中的更改。

   • 軟重置（Soft Reset）：保留工作目錄和暫存區中的所有更改。

     git reset --soft <commit-hash>
     

   • 混合重置（Mixed Reset，默認選項）：保留工作目錄中的更改，但重置暫存區。

     git reset --mixed <commit-hash>
     

   • 硬重置（Hard Reset）：丟棄工作目錄和暫存區中的所有更改，回到指定提交的狀態。

     git reset --hard <commit-hash>
     

     [!caution]

     使用--hard的時候要特別小心，它會丟失未提交的更改。

關于HEAD的說明，回退的版本可以直接使用commit對象的id，也可以這樣：

• HEAD：表示當前版本。
• HEAD^：表示上一個版本。
• HEAD^^：表示上上個版本。
• HEAD^^^：表示上上上個版本。

使用^不方便也可以使用數字。

• HEAD~0 ：表示當前版本。
• HEAD~1：表示上一個版本。
• HEAD~2：表示上上個版本。

依次類推。

版本回退的演示

1. 首先打印我們提交過的所有版本：

   

   • 左邊是commit id，雖然是一部分，但是也可以進行回退。

2. 直接硬重置到第一次提交到版本：

   

3. 假設我們后悔了，想回退到剛剛的版本，后面更那次提交的commit id即可：

   

文件又回來了，但是有時候我們可能清屏了，該如何找到commit id呢？可以通過如下指令：

git reflog

它記錄本地每次提交的commit id：

版本回退的速度是很快的，因為它只是將HEAD指針移動到不同的commit對象。

撤銷修改–情況1

有時候我們工作區寫了一大堆代碼，但是發現寫的不怎么行，想要回退到上一個版本，應該怎樣做呢？

1. 直觀的辦法就是直接手動刪除，但是這種辦法及其容易出錯，因為我們可能誤刪，如果寫的代碼太多的話。

2. **git給我們提供了一個命令，讓我們的文件可以回退到上一次add或者commit**的版本：

   git checkout -- [file]
   

   • --不能省略。

3. 下面我們簡單演示下，先查看file.txt文件的內容：

   

4. 直接回退到上一次add或者commit：

   

回退成功。

撤銷修改–情況2

已經add，但是還沒有commit，我們可以先進行版本回退，將暫存區的修改回退到上一次提交，使用：

git reset  --mixed [file]

下面來演示下：

1. 修改file.txt的內容，并add：

   

2. 回退暫存區的內容為上一個版本的：

   

3. 此時和情況1一樣，使用情況1的指令：

   git checkout -- file.txt
   

   

撤銷修改–情況3

已經add了，并且也commit了。

我們可以使用版本回退到硬重置git reset --hard：

git reset --hard HEAD^

• 硬重置到上一個版本。但是這是有條件的，就是你還沒有將這次提交的內容推送到遠程。對于已推送的,不建議直接硬重置，因為這會破壞遠程倉庫的歷史記錄。

1. 下面我們修改file.txt，并將其add并commit：

   

2. 然后將其工作區、暫存區、版本庫全部到回退到上一個提交版本：

   

刪除文件

從工作區中刪除文件也是一種修改，我們來研究一下刪除文件的情況。

1. 從分支中刪除文件file.txt：

   

2. 此時工作區中確實已經刪除了文件file.txt，但假設我們是誤刪，如何恢復呢，很簡單使用撤銷修改中的情況1里面的操作即可：

   #將file.txt回退到最近一次add 或者commit
   git checkout -- file.txt
   

   

3. 但是如果是真的不想要這個文件了，那么就需要刪干凈，因為暫存區和版本庫中還存在這個文件：

   

4. 我們使用git rm命令：git rm 是 Git 中用于從工作目錄和索引（即暫存區）中刪除文件的命令。它不僅會將文件從當前分支的工作目錄中刪除，還會將其從暫存區中移除，這意味著在下次提交時，該文件將不再存在于倉庫的歷史記錄中（至少是從這次提交開始的未來歷史中）。

   

   • 刪除了還要提交，只要提交版本庫中才會更新。

分支管理

什么是分支

在 Git 中，分支（branch） 是一個核心概念，它允許開發者在同一代碼庫中并行地開發不同的功能、修復 bug 或進行實驗，而不會互相干擾。分支實質上是對提交歷史的一個指針或引用，指向某一系列的提交（commits）。

每一個分支，隨著每一次的commit都會變長，它就像一條時間線，每一條時間線我們可以看作是一條分支，HEAD指向當前分支：

而這個文件保存的就是最新提交的commit。

分支操作

創建新的分支

git branch <branch-name>

• <branch-name>：是你想創建的分支的名稱。

• 如果后面不加分支名，就是查看本地所有分支。

切換分支

git checkout <branch-name>

[!caution]

注意，沒有--。

切換分支的本質就是HEAD指向了不同的分支文件。

合并分支

git merge [branch-name]

• 注意如果你想將某一個分支的內容合并到master主分支上，那么必須要切換到master分支下再合并。

刪除分支

合并分支后，說明開發已經完成了，可以刪除不需要的分支，想刪除某個分支，也必須不能在該分支上。

git branch -d [branch-name]

演示上述操作

1. 查看當前的所有分支：

   

2. 只有一個master，我們新建一個分支dev：

   

3. 切換分支到dev：

   

4. 修改內容后（我們是在記事本中修改的），合并分支：

   

5. 現在合并成功了，刪除掉分支dev即可：

   

上述過程我們畫成時間線的圖就是這樣:

合并沖突

在合并的時候，我們可能遇見兩個分支都修改內容的情況，就有可能出現沖突，這個時候我們就需要去手動解決沖突，因為git不清除你要保留那些內容。

下面我們來模擬一下沖突的情況:

1. 首先查看當前的所有分支：

   

2. 我們創建一個分支dev，創建之后還要切換分支，我們可以使用下面的命令創建并切換：

   git checkout -b dev
   

   

3. 給file.txt文件增加一行內容：aaaaaa on dev，add并提交：

   

4. 切換到master分支下，也給file.txt文件增加一行內容bbbbbb on master，add并提交：

   

5. 此時直接在master分支下合并dev分支會出現沖突：

   

   • 出現了沖突，我們需要解決完沖突再提交一次，然后才能合并。

6. 此時我們打開file.txt是這樣的：

   

7. 我們保留dev下的內容，刪掉多余的符號：

   

8. 在master分支上解決完沖突后，然后再提交一次，就解決完沖突合并成功了：

   

9. 我們使用下面的命令圖形化的顯示提交情況：

   git log --graph --oneline --all  
   

   

分支合并的策略–兩種模式

1. 快進合并（Fast-Forward Merge）：當目標分支（如 main）沒有新的提交時，Git 會簡單地將指針向前移動到被合并分支的最新提交，不會創建新的合并提交。這樣有個缺點就是不能看出來當前的提交是合并的還是一直在一個分支上開發的。
2. 三方合并（Three-Way Merge）:當目標分支（如 main）有新的提交時，Git 會創建一個新的合并提交（Merge Commit），以記錄兩個分支的歷史交匯點。

默認情況下是fast-forward模式，但是出現沖突時就是no-ff模式（三方合并），我們可以使用no-ff選項強制使用這種模式。

下面我們來演示一下這兩種模式：

Fast-Forward模式演示

1. 創建進入新的分支dev：

   

2. 給dev分支中的file.txt文件增加一行內容：

   

3. 切換到master下并合并：

   

4. 使用git log命令查看圖形化的提交線：

   

5. 檢查dev、master分支的最新提交是否是一樣的：

   

Three-Way模式演示

1. 進入dev分支，繼續在file.txt上添加一行新內容：

   

2. 切換回master分支，這次使用no-ff模式合并：

   git merge --no-ff dev
   

   

   • 下面的內容是不是很眼熟，**這不是commit的時候才會出現的內容嗎？**說明這種模式下，會重新提交一次。

3. git log查看提交日志：

   

4. 檢查dev、master分支的最新提交是否是一樣的：

   

• 不一樣說明此次合并，在Three-Way模式下的確是多進行了一次提交。

在dev分支開發時，主分支上出現了bug

有時候我們在dev分支上開發，因為master分支上必須放穩定的代碼，它是屬于線上環境，必須要保證安全性，而其他分支就一般是日常開發環境，是不穩定的。此時dev上的代碼還沒add和commit。

1. 在dev分支上開發的代碼，如果沒有add或commit，在master或者其他分支中是能看到變化的：

   • 這是因為，工作區是全局的，工作區是指你當前文件系統中的文件狀態，它與具體的分支無關。而暫存區和版本庫是分支相關的。只有當你執行git add或git commit中改動才會被 記錄到當前分支中。

2. 模擬在dev上開發代碼然后沒有添加到暫存區：

   

3. 我們要先解決master的bug，dev上的修改不能影響到我們，所以需要先將dev工作區的內容存到一個地方，但是又不能提交因為還沒有開發完，.git中確實有這么個區域：

   git stash。它允許你將當前工作區的修改（包括暫存區的內容）臨時存儲起來，而不需要提交這些修改。這樣，你可以切換到其他分支（如 master）去修復 Bug，等完成后可以再恢復這些修改繼續開發。

4. 我們切換回dev中，將開發了但未開發完的file.txt先存起來：

   

5. 在.git/refs/目錄下，有一個stash文件，這會將工作區和暫存區的所有修改（包括新增、修改和刪除的文件）保存到儲藏區，并將工作區恢復到最近一次提交的狀態。

   

6. 我們可以使用下面的命令查看儲藏區的儲藏列表：

   git stash list 
   

   

7. 然后我們就可以去master中再去開一個分支用于修改bug了。

8. 假設此時我們已經修改完了bug，想要回到dev中繼續開發該如何將儲藏區的內容拿出來的，使用如下選項：

   git stash pop
   

   

9. 此時假設已經開發完了再合并，我們建議先在dev上合并master，因為如果遇見沖突，修改的也是dev上的內容，即使修改錯了也不影響線上環境，這種方式比較安全：

   

10. 然后再切換到master上，進行合并：

    

11. master與dev進行合并：

    

強制刪除分支

1. 有時候我們在dev分支上開發了一段時間，也提交了突然不想要這些功能了，直接在主分支上使用git branch -d是無法刪除的，因為還沒有合并：

   

2. 此時可以使用-D強制將其刪除：

   

理解分布式

Git 是一種分布式版本控制系統（DVCS, Distributed Version Control System），與傳統的集中式版本控制系統（如 SVN）相比，它提供了更多的靈活性和控制力。

• 也就是說同一個git管理的倉庫，可以在不同的主機上開發，將來通過網絡（局域網）推送、拉取即可。但是這樣做有一個不好的點，就是如果兩個開發者沒有在同一個局域網或者存儲最新版本的主機宕機了，豈不是無法拉取內容了。

所以有了中央服務器的誕生，它們部署在公網，可以24小時的訪問，幫助開發者維護遠程倉庫：

GitHub 和 Gitee 都是基于 Git 的代碼托管平臺，它們提供了遠程倉庫服務，使得開發者可以方便地在團隊中協作開發軟件項目。

這樣開發時，一個項目的人員只需要通過這個中央服務器，就可以輕松的進行多人協作開發了：

遠程倉庫相關操作

將遠程倉庫克隆到本地–HTTPS

1. 當我們新建好一個遠程倉庫后，如何將其clone到本地呢？

   

2. 可以看到點克隆是會有多種方法的，這里我們選擇HTTPS，復制代碼到一個沒有git倉庫的目錄下：

   

3. 查看我們當前用戶對于這個倉庫的權限：

   git remote -v
   

   • 最前面是倉庫的默認名稱。

   

將遠程倉庫克隆到本地–ssh

與https方式的不同就是多了一步本地生成，并在gitee上配置公鑰的過程。SSH 使用公鑰和私鑰對進行身份驗證，而 HTTPS 使用用戶名和密碼（或個人訪問令牌）。

推送操作

我們克隆遠程倉庫之后，想要將本地的提交推送到遠程倉庫中，應該怎么做呢？學習如下指令。

git push origin <分支名>

下面我們來演示一下：

1. 在本地倉庫新建一個文件，add后commit:

   

2. 直接提交，第一次提交可能有點慢：

   

3. 查看遠端，是否提交成功：

   

拉取操作

當其它開發者，開發之后將代碼提交到了中心倉庫gitee/github服務器上，我們想看到相應的內容，就可以去執行拉取操作，拉取操作的作用是從遠程倉庫獲取最新的更改，并將其合并到本地分支中。通過拉取，我們可以確保本地代碼與遠程倉庫保持同步。

1. 我們模擬其它開發者提交新的源碼文件，這里我們可以直接在倉庫上做更改，但實際中不建議這樣做：

   

2. 執行下面指令進行拉取操作：

   git pull origin master
   

   

3. git pull實際是以下兩個命令的組合：

   • git fetch：從遠程倉庫下載最新的提交和更改。
   • git merge：將下載的內容合并到當前分支。

4. 實際我們進行拉取的時候，也可能出現合并沖突的問題，這個時候也需要手動解決沖突，這樣來做

   • Git 會標記沖突的文件。打開沖突文件，找到沖突的部分（通常被 <<<<<<< 和 >>>>>>> 包裹）。

   • 修改代碼以解決沖突。

   • 標記沖突已解決并提交：

忽略一些特定后綴的文件

有時候我們的項目中不想提交一些除了源碼之外的文件，但是一個文件一個文件的git add還是太麻煩了，我們希望簡單點使用git add .一鍵將所有文件添加到暫存區，但是又不想提交一些特定后綴的文件，這個時候應該怎么辦呢？

• 對此git也給我們提供了解決方案，它里面有一種特點的文件，叫做.gitignore，它位于項目的根目錄下，通常需要我們手動創建。

1. 創建.gitignore文件，忽略所有后綴為.so文件：

   

2. 但是我們想對b.so進行提交，兩種做法：

   • git add -f [name]：-f表示強制提交。

   • 也可以在.gitignore文件中添加!b.so表示不排除b.so文件。

     

3. 我們創建一個b.so看是否被忽略：
   

4. 有時候我們發現某個文件被忽略了，但是.gitignore規則太多，想快速查看是哪個規則影響了，可以使用以下命令：

   git check-ignore -v [文件名]
   

5. 比如此時我們想看看，1.so為什么被忽略：

   

6. add并commit剛剛新增且沒有被忽略的文件，然后推送給遠程：

   

7. 查看遠程倉庫，確實成功推送了，也是我們預期的結果：

   

對具有里程碑意義的提交進行打標簽操作

打標簽

我們可以對某些具有里程碑意義的提交進行打標簽，代表這是一次重要的版本。

git tag [標簽名] [提交哈希]

• 如果不寫提交哈希（也就是commit id），就是默認是對最新一次提交打標簽。

我們嘗試給最新一次提交打標簽：

查看所有標簽

下面命令可以查看所有已經存在的標簽：

git tag

推送標簽到遠端

下面命令可以將某一個標簽推送到遠端：

git push origin [標簽名]

如果你想一鍵推送所有標簽，可以加上下面選項：

git push origin --tags

給標簽加上描述信息

下面命令可以創建標簽并添加上描述信息：

git tag -a [標簽名] -m [描述信息]

刪除標簽并推送到遠端

有時候我們的標簽可能打錯了，就需要在遠端和本地都刪除掉這個標簽。

1. 在本地刪除標簽：

   git tag -d [標簽名]
   

   

2. 將標簽的刪除，推送至遠端：

   git push origin :[標簽名]