目錄

Git 初識

Git 安裝（Linux-ubuntu）

Git 基本操作

創(chuàng)建 Git 本地倉庫

配置 Git

認(rèn)識工作區(qū)、暫存區(qū)、版本庫

添加文件

查看 .git 文件

修改文件

版本回退

撤銷修改

情況一：對于工作區(qū)的代碼，還沒有 add

情況二：已經(jīng) add ，但沒有 commit

情況三：已經(jīng) add ，并且也 commit 了?

刪除文件

分支管理

理解分支

創(chuàng)建分支

切換分支

合并分支

刪除分支

合并沖突

分支管理策略

分支策略

bug 分支

刪除臨時分支

通過學(xué)習(xí)?Git ，我希望我們能夠達(dá)成以下目標(biāo)：?

? 技術(shù)目標(biāo): 深入掌握Git在企業(yè)級應(yīng)用中的運用，包括對Git操作流程和原理的深刻理解，以及對工作區(qū)、暫存區(qū)和版本庫的含義的準(zhǔn)確把握。

? 技術(shù)目標(biāo): 掌握Git版本管理的各種操作方式及其背后的操作原理，包括但不限于版本回退、撤銷、修改等操作，以實現(xiàn)對代碼版本的靈活管理。

? 技術(shù)目標(biāo): 從分支的創(chuàng)建、切換、合并到刪除等整個生命周期的掌握，能夠靈活應(yīng)對各種場景下的分支管理，并學(xué)習(xí)常見的分支管理策略。

? 技術(shù)目標(biāo): 結(jié)合版本管理與分支管理，熟練掌握Git遠(yuǎn)程倉庫與本地倉庫的交互操作，實現(xiàn)基于分支級別的個人級開發(fā)。

? 技術(shù)目標(biāo): 理解分布式版本控制系統(tǒng)的原理，學(xué)習(xí)多人協(xié)作開發(fā)模式，掌握遠(yuǎn)程倉庫與本地倉庫之間的協(xié)同操作。

? 協(xié)作目標(biāo): 學(xué)習(xí)企業(yè)級常見的分支策略，如master/release/develop/feature/hotfix等，理解不同公司、不同環(huán)境下適用的分支模型。通過案例引入工程師、測試人員、技術(shù)經(jīng)理等不同角色，展示項目開發(fā)過程的整體流程，從而深入理解Git在其中的作用。

Git 初識

在工作或?qū)W習(xí)過程中，經(jīng)常會遇到需要對文檔或項目代碼進(jìn)行版本管理的情況。這種情況下，我們會發(fā)現(xiàn)隨著版本的不斷迭代，手動管理多個版本的文檔或代碼變得非?；靵y和困難。

通常情況下，我們會為了保留文檔或代碼的不同版本而不得不創(chuàng)建多個副本，每個副本都帶有不同的版本號或描述，比如“報告-v1”、“報告-v2”等。這種做法可能會導(dǎo)致以下問題：

1. 版本混亂和記憶困難： 隨著版本的增多，很容易忘記每個版本所做的修改或者特定版本的內(nèi)容。這使得在需要時很難回溯到特定版本或者了解每個版本的變化。

2. 副本過多導(dǎo)致管理困難： 隨著版本的不斷增加，每個版本都會產(chǎn)生一個副本，這會導(dǎo)致文件系統(tǒng)中出現(xiàn)大量的副本文件，增加了管理的復(fù)雜性。同時，找到特定版本的文件也變得更加困難。

3. 工作效率低下： 每次創(chuàng)建新版本或者回滾到之前的版本都需要手動復(fù)制、重命名或者移動文件，這樣的操作會消耗大量的時間和精力，降低了工作效率。

4. 無法有效協(xié)作： 如果多人共同編輯同一份文檔或同一個項目，手動管理多個版本的文件會帶來溝通不暢、協(xié)作困難等問題，容易導(dǎo)致沖突和誤解。

因此，了解和掌握Git這樣的版本控制工具變得至關(guān)重要。Git可以幫助我們有效地管理文檔和代碼的版本，輕松地回溯到特定版本，跟蹤修改歷史，協(xié)作開發(fā)，提高工作效率，并減少由手動管理版本所帶來的錯誤和混亂。

什么是版本控制工具？我們來詳細(xì)了解一下。

如何解決——版本控制器

正如先前所提到的，通常情況下，我們可能會遇到需要維護(hù)多個版本的文檔或代碼，以便于回溯修改、找回之前的版本或者與團(tuán)隊成員共享不同的進(jìn)度。在沒有版本控制工具的情況下，我們可能會通過復(fù)制粘貼副本的方式來管理不同版本，但隨著版本數(shù)量的增加，會導(dǎo)致文件混亂、難以追蹤每個版本的修改內(nèi)容等問題。

為了解決這些問題，版本控制器應(yīng)運而生。版本控制器能夠記錄文件的歷史修改記錄，展示其發(fā)展過程，為我們提供了一種系統(tǒng)化的管理方式。

簡單來說，版本控制器就是能夠記錄每次工程改動和版本迭代的管理系統(tǒng)，同時也能方便多人協(xié)同作業(yè)。

具體來說，版本控制器可以看作是一種軟件工具，旨在幫助開發(fā)團(tuán)隊有效地管理和協(xié)調(diào)其項目中的源代碼和其他文件。其核心功能包括記錄文件的歷史修改記錄、管理文件的不同版本、協(xié)調(diào)團(tuán)隊成員之間的合作以及管理項目的整體進(jìn)展。

1. 歷史修改記錄的記錄和管理：版本控制器能夠記錄每次文件的修改，包括修改內(nèi)容、修改時間、修改人等信息。這樣可以輕松地追溯文件的演變歷程，了解每個版本的變動細(xì)節(jié)。

2. 版本的管理：版本控制器能夠存儲文件的不同版本，并支持方便快捷地切換和回溯到特定的版本。這樣，開發(fā)團(tuán)隊可以在需要時方便地恢復(fù)到之前的版本，或者比較不同版本之間的差異。

3. 多人協(xié)同作業(yè)：版本控制器為多人協(xié)同作業(yè)提供了便利。團(tuán)隊成員可以同時編輯同一個文件，版本控制器會自動合并他們的修改，并提供解決沖突的機制。這樣可以避免因為多人同時編輯而產(chǎn)生的沖突和混亂。

4. 分支管理：版本控制器支持分支管理，允許開發(fā)團(tuán)隊在不同的開發(fā)任務(wù)或功能之間創(chuàng)建獨立的分支。每個分支都可以獨立進(jìn)行開發(fā)和測試，然后再合并回主分支。這樣可以有效地組織項目的開發(fā)流程，提高開發(fā)效率。

5. 遠(yuǎn)程倉庫管理：許多版本控制器還提供了遠(yuǎn)程倉庫的功能，允許團(tuán)隊將項目代碼托管到云端服務(wù)器上。這樣團(tuán)隊成員可以隨時隨地訪問和共享項目代碼，實現(xiàn)分布式團(tuán)隊的協(xié)作。

由此可見，版本控制器是一種強大的工具，為軟件開發(fā)團(tuán)隊提供了有效的項目管理和協(xié)作平臺。通過記錄文件的修改歷史、管理不同版本、支持多人協(xié)同作業(yè)和分支管理等功能，版本控制器可以幫助團(tuán)隊提高工作效率、降低開發(fā)成本，并保證項目的質(zhì)量和穩(wěn)定性。

而目前最主流的版本控制器是Git。Git具有管理電腦上所有格式的文件的能力，包括doc、excel、dwg、dgn、rvt等等。對于開發(fā)人員來說，Git最重要的功能之一就是能夠幫助我們有效地管理軟件開發(fā)項目中的源代碼文件，使得團(tuán)隊成員能夠協(xié)同工作，并且能夠方便地追蹤、回溯和管理代碼的變更歷史。

注意事項

需要明確的一點是，所有的版本控制系統(tǒng)，包括Git在內(nèi)，實際上只能跟蹤文本文件的改動，比如TXT文檔、網(wǎng)頁、以及所有的程序代碼等等。版本控制系統(tǒng)能夠告訴你每次的改動，比如在第5行添加了一個單詞“Linux”，在第8行刪除了一個單詞“Windows”等等。

對于圖像、視頻等二進(jìn)制文件，雖然它們也可以由版本控制系統(tǒng)管理，但版本控制系統(tǒng)無法跟蹤文件的具體變化，它只能記錄二進(jìn)制文件每次改動的大小變化，比如從100KB變成了120KB，但無法知道具體修改了什么內(nèi)容。因此，對于這些二進(jìn)制文件，版本控制系統(tǒng)只能將它們的改動串聯(lián)起來，而無法具體展示每次改動的細(xì)節(jié)。

Git 安裝（Linux-ubuntu）

Git是一款開放源代碼的分布式版本控制系統(tǒng)，最初是由Linus Torvalds為了管理Linux內(nèi)核開發(fā)而開發(fā)的。起初，Git主要用于Linux平臺，并且在Linux下得到了廣泛的應(yīng)用。隨著時間的推移，Git逐漸被移植到了其他操作系統(tǒng)平臺，如Windows、Unix和Mac OS等，現(xiàn)在已經(jīng)可以在這幾大平臺上正常運行。

這種跨平臺的特性使得Git成為了一款廣泛使用的版本控制工具，無論是在開源項目中還是在商業(yè)項目中，都得到了廣泛的應(yīng)用。無論開發(fā)者使用的是哪種操作系統(tǒng)，他們都可以通過Git來管理和追蹤項目的代碼，實現(xiàn)代碼的版本控制和團(tuán)隊協(xié)作。這也使得Git成為了現(xiàn)代軟件開發(fā)中不可或缺的重要工具之一。

在 Ubuntu 平臺上安裝 Git 是非常簡單的。以下是安裝 Git 的步驟：

首先，我們可以嘗試在終端輸入 git 命令，看看系統(tǒng)是否已經(jīng)安裝了 Git。

如果系統(tǒng)沒有安裝 Git，會得到類似如下的提示：

此時這表示 Git 尚未安裝。

通過以下命令安裝 Git：

這條命令將使用 apt-get 包管理器來安裝 Git。加上 -y 參數(shù)表示自動確認(rèn)安裝，無需手動確認(rèn)安裝過程中的提示信息。

安裝完成后，我們可以通過以下命令來驗證 Git 是否成功安裝以及查看 Git 的版本信息：

這將顯示已安裝的 Git 版本號，確認(rèn)安裝成功。

通過上述步驟，我們就可以在 Ubuntu 上成功安裝 Git，并開始使用它進(jìn)行版本控制和開發(fā)工作。

Git 基本操作

創(chuàng)建 Git 本地倉庫

倉庫是進(jìn)行版本控制的一個文件目錄或者存儲空間。

在Git中，倉庫是用來存儲項目的所有文件和歷史變更記錄的地方。我們要對文件進(jìn)行版本控制，首先需要在本地或者遠(yuǎn)程創(chuàng)建一個倉庫。

在Git中，我們可以通過以下兩種方式創(chuàng)建倉庫：

1、本地倉庫：在本地計算機上創(chuàng)建一個Git倉庫，用于存儲本地項目的文件和版本記錄。這種方式適用于個人項目或者本地開發(fā)。

若要在當(dāng)前目錄下創(chuàng)建一個新的Git倉庫，可以使用以下命令：

git init

這將在當(dāng)前目錄下創(chuàng)建一個名為 .git 的隱藏文件夾，作為Git倉庫，用來存儲項目的版本歷史和元數(shù)據(jù)。

2、遠(yuǎn)程倉庫：在遠(yuǎn)程服務(wù)器上創(chuàng)建一個Git倉庫，用于存儲項目的文件和版本記錄，并允許多個開發(fā)者之間共享和協(xié)作。這種方式適用于團(tuán)隊項目或者需要跨多個開發(fā)者協(xié)作的項目。

若要在遠(yuǎn)程服務(wù)器上創(chuàng)建一個新的Git倉庫，可以使用Git托管服務(wù)（如GitHub、GitLab、Bitbucket等）提供的界面或者命令行工具。在網(wǎng)站上創(chuàng)建好倉庫后，可以通過以下命令將本地倉庫關(guān)聯(lián)到遠(yuǎn)程倉庫：

git remote add origin <遠(yuǎn)程倉庫地址>

這將在本地倉庫中添加一個名為 origin 的遠(yuǎn)程倉庫地址。

其中第二種遠(yuǎn)程操作我們后續(xù)會系統(tǒng)的學(xué)習(xí)，現(xiàn)在先不做過多了解。

我們此處就使用第一種方式來創(chuàng)建一個本地倉庫：

上面我們已經(jīng)使用 git init 命令初始化了一個空的Git倉庫。在這個命令執(zhí)行后，系統(tǒng)提示我正在使用 master 作為初始分支的名稱，并給出了一些關(guān)于默認(rèn)分支名更改的提示信息。同時，Git成功地在 /home/ubuntu/gitcode/.git/ 目錄下初始化了一個空的Git倉庫，該倉庫將用于存儲項目的版本歷史和元數(shù)據(jù)。

你可以清楚地看到在當(dāng)前目錄下多了一個 .git 的隱藏文件， .git 目錄是Git用來跟蹤和管理倉庫的關(guān)鍵組成部分，它包含了Git倉庫的所有版本歷史和元數(shù)據(jù)信息。在這個目錄下存儲了Git的配置、歷史記錄、分支信息等內(nèi)容，對其進(jìn)行手動修改可能會導(dǎo)致Git倉庫損壞。

因此，在使用Git的過程中，我們千萬不要手動修改 .git 目錄下的任何文件，以免意外破壞了Git倉庫的完整性。一般情況下，我們只需要通過Git提供的命令來管理和操作倉庫，如添加文件、提交修改、切換分支等，Git會自動更新 .git 目錄下的相關(guān)文件以反映這些操作的變化。

?既然這個文件包含了 Git 倉庫的諸多細(xì)節(jié)，那么我們就進(jìn)去看看：

?

• branches：該目錄用于存儲分支的相關(guān)信息。
• config：Git 倉庫的配置文件，包含了倉庫的各種配置信息。
• description：該文件包含了對倉庫的描述信息。
• HEAD：指向當(dāng)前工作分支的指針。
• hooks：該目錄包含了一系列 Git 鉤子腳本，這些腳本可以在特定的 Git 操作觸發(fā)時執(zhí)行相應(yīng)的動作。
• info：該目錄包含了一些倉庫的額外信息，如排除文件等。
• objects：該目錄用于存儲 Git 對象，包括文件內(nèi)容、目錄結(jié)構(gòu)、提交信息等。
• refs：該目錄包含了分支和標(biāo)簽的引用。

這些文件和目錄構(gòu)成了Git倉庫的基本結(jié)構(gòu)，每個部分都有其特定的作用和功能，用于存儲倉庫的各種信息和元數(shù)據(jù)。通過這些文件和目錄，Git能夠管理和跟蹤項目的版本歷史、分支、標(biāo)簽等內(nèi)容，實現(xiàn)有效的版本控制和管理。

創(chuàng)建好倉庫后，我們就可以開始向倉庫中添加文件、提交修改、查看歷史記錄等操作，實現(xiàn)對文件的版本控制和管理了。

配置 Git

當(dāng)安裝 Git 后首先要做的事情是設(shè)置我們的 用戶名稱 和 e-mail 地址，這是非常重要的。

設(shè)置用戶名稱和電子郵件地址是安裝Git后的重要步驟之一。這些信息將與每次提交的代碼一起記錄在Git的提交歷史中，幫助其他開發(fā)者和團(tuán)隊成員識別誰提交了特定的更改，以及如何聯(lián)系到該開發(fā)者。

要設(shè)置用戶名稱和電子郵件地址，可以使用以下Git命令：

設(shè)置用戶名稱：

git config [--global] user.name "Your Name"

設(shè)置電子郵件地址：

git config [--global] user.email "your.email@example.com"

你也可以使用

git config --unset user.name
git config --unset user.email

命令刪除相關(guān)配置項。

細(xì)心的話你會發(fā)現(xiàn)，我們上面的代碼樣例里面給出了[--global]。

當(dāng)設(shè)置用戶名稱和電子郵件地址時，[--global] 是一個可選項，它影響了配置的作用范圍：

1. --global選項的作用：

   • 當(dāng)使用 git config --global 命令來設(shè)置用戶名稱和電子郵件地址時，加上 --global 選項，表示這個設(shè)置將應(yīng)用到當(dāng)前用戶的所有Git倉庫中。
   • 這意味著不論我們在哪個Git倉庫中執(zhí)行提交操作，都會使用相同的用戶名稱和電子郵件地址。這是因為這些配置信息保存在用戶主目錄下的一個特殊文件中（通常是 ~/.gitconfig），被所有的Git倉庫共享。

2. 不使用--global選項的情況：

   • 如果在設(shè)置用戶名稱和電子郵件地址時不使用 --global 選項，則這個設(shè)置僅適用于當(dāng)前所在的Git倉庫。
   • 這意味著這些配置信息只會應(yīng)用于當(dāng)前的Git倉庫，而不會影響其他倉庫或者全局的設(shè)置。這些設(shè)置將保存在當(dāng)前倉庫的 .git/config 文件中，只對當(dāng)前倉庫生效。

3. 在不同倉庫中使用不同的配置：

   • 如果我們希望在不同的Git倉庫中使用不同的用戶名稱和電子郵件地址，可以選擇不使用 --global 選項，而是在每個倉庫中單獨設(shè)置。
   • 要注意的是，如果我們在使用 --global 選項時設(shè)置了全局的用戶名稱和電子郵件地址，然后在某個倉庫中又單獨設(shè)置了不同的值，那么在該倉庫中將會使用該倉庫的設(shè)置而不是全局設(shè)置。

綜上所述，使用 --global 選項可以方便地將用戶名稱和電子郵件地址配置應(yīng)用到所有的Git倉庫中，而不使用該選項則可以在不同的倉庫中使用不同的配置。但無論使用哪種方式，都需要在倉庫內(nèi)使用 git config 命令來進(jìn)行設(shè)置。

至于使用了 --global 設(shè)置的配置項怎么刪除？

同樣添加 --global 即可：

git config --global --unset user.name
git config --global --unset user.email

認(rèn)識工作區(qū)、暫存區(qū)、版本庫

1. 工作區(qū)：

   • 工作區(qū)是指我們電腦上用于編寫代碼或文件的目錄。在這個目錄下，我們可以創(chuàng)建、編輯和修改文件，進(jìn)行開發(fā)工作。
   • 通常情況下，我們的項目文件都會存放在工作區(qū)中，這些文件是我們正在進(jìn)行開發(fā)和編輯的。

2. 暫存區(qū)：

   • 暫存區(qū)（英文稱為 stage 或 index）是Git的一個重要概念，它是一個緩存區(qū)域，用于暫時存放我們已經(jīng)修改的文件，但是還沒有提交到版本庫中。
   • 暫存區(qū)一般存放在 .git 目錄下的 index 文件（.git/index）中，因此有時也被稱為索引（index）。
   • 當(dāng)我們對工作區(qū)中的文件進(jìn)行修改后，可以通過 git add 命令將這些修改添加到暫存區(qū)中，然后通過 git commit 命令將暫存區(qū)中的修改提交到版本庫中。

3. 版本庫：

   • 版本庫（又名倉庫，英文名 repository）是Git的核心部分，它包含了我們項目的所有文件和相應(yīng)的版本歷史記錄。
   • 在我們的工作區(qū)中有一個隱藏目錄 .git，這個目錄就是Git的版本庫。這個版本庫中包含了我們項目的所有版本信息和元數(shù)據(jù)。
   • Git會跟蹤并記錄版本庫中所有文件的修改、刪除等操作，因此我們可以隨時追蹤項目的歷史，或者在需要的時候回溯到之前的某個狀態(tài)。
   • 版本庫中的文件經(jīng)過Git管理，我們可以使用各種Git命令來查看文件的歷史記錄、比較不同版本之間的差異、撤銷修改等操作，以實現(xiàn)對項目的版本控制和管理。

總之，工作區(qū)是我們實際進(jìn)行開發(fā)的地方，暫存區(qū)是用來暫存即將提交到版本庫中的修改，版本庫是Git用來存儲項目的所有版本歷史和元數(shù)據(jù)的地方。這三者共同構(gòu)成了Git的基本工作流程，幫助我們有效地管理項目文件的版本和修改。

下面這個圖展示了工作區(qū)、暫存區(qū)和版本庫之間的關(guān)系：

在Git中，我們的工作區(qū)和版本庫扮演著關(guān)鍵的角色。工作區(qū)代表了我們當(dāng)前正在操作的目錄，其中包含我們正在開發(fā)的代碼文件或其他項目文件。在圖中，我們可以看到左側(cè)表示工作區(qū)，即我們實際進(jìn)行編輯和修改的地方。而右側(cè)則代表版本庫，是Git用來存儲項目的所有版本歷史和元數(shù)據(jù)的地方。版本庫中包含了我們項目的所有文件以及每個文件的歷史版本信息。

通過上圖，我們可以總結(jié)出Git中文件的管理流程：

1. 創(chuàng)建Git版本庫：當(dāng)我們使用Git創(chuàng)建一個新的版本庫時，Git會自動為我們創(chuàng)建一個默認(rèn)的主要分支，通常稱為 master 分支。同時，Git還會創(chuàng)建一個指向當(dāng)前分支的指針，稱為 HEAD。這兩個概念是Git中非常重要的，它們幫助我們確定當(dāng)前所在的分支或提交狀態(tài)。
2. 對工作區(qū)的文件進(jìn)行修改或新增：當(dāng)我們在工作區(qū)修改、刪除或新增文件時，這些文件處于未跟蹤狀態(tài)，Git并不會自動將它們添加到版本庫中。為了將這些修改、刪除或新增的文件納入Git的管理范圍，我們需要使用 git add 命令。這個命令將工作區(qū)中的修改添加到Git的暫存區(qū)中，并更新暫存區(qū)目錄樹的文件索引。
3. 執(zhí)行提交操作：當(dāng)我們確認(rèn)要提交暫存區(qū)中的修改時，我們使用 git commit 命令。這個命令會將暫存區(qū)中的內(nèi)容提交到版本庫中，成為一個新的版本歷史記錄。這意味著暫存區(qū)中的修改會被真正寫入到版本庫中，從而成為項目的一部分。? ?
   在提交操作完成后，master 分支會相應(yīng)地更新，指向新的提交，以反映項目的最新狀態(tài)。這個過程中，我們的項目的發(fā)展歷程得到了保留和記錄，使得我們能夠隨時回溯項目的歷史變化。

Git的文件管理流程包括將工作區(qū)中的修改添加到暫存區(qū)，然后將暫存區(qū)中的內(nèi)容提交到版本庫中。這個過程中，Git的分支和HEAD指針起到了重要的作用，幫助我們確定當(dāng)前所在的分支和提交狀態(tài)，并實現(xiàn)對項目的導(dǎo)航和操作。

根據(jù)上述描述，我們可以得知：僅僅通過新建或粘貼進(jìn)工作區(qū)的文件，并不能稱之為向倉庫中新增文件，而只是在工作區(qū)新增了文件。要將文件添加到倉庫中進(jìn)行管理，必須通過使用 git add 和 git commit 命令來完成！

這個過程確保了我們對項目文件的修改是有意識的，并且能夠明確地將這些修改記錄到版本庫中，以便日后追溯和管理。因此，Git的版本控制機制使得我們能夠更加有效地管理項目的代碼和文件。

但是我們還是有一些沒搞明白的地方：git add 命令到底做了什么？git add 命令呢？版本庫的版本控制具體又是怎么做到的呢？?

當(dāng)我們使用 git add 命令時，實際上發(fā)生了一系列的操作，主要是將工作區(qū)的修改內(nèi)容添加到Git的暫存區(qū)中。具體來說，git add 命令執(zhí)行以下幾個步驟：

1. 檢查工作區(qū)的文件變化：首先，Git會檢查工作區(qū)中的文件，比較當(dāng)前文件和上一次提交時的版本之間的差異，以確定哪些文件發(fā)生了修改或新增。

2. 創(chuàng)建新的Git對象：當(dāng)檢測到文件的修改或新增時，Git會為每個被修改的文件創(chuàng)建一個新的Git對象。這個對象包含了文件的內(nèi)容以及相關(guān)的元數(shù)據(jù)，如文件名、修改時間等。

3. 將對象寫入對象庫：這些新創(chuàng)建的Git對象會被寫入到Git的對象庫中，即.git/objects目錄下。對象庫是Git中用來存儲所有版本歷史和文件內(nèi)容的地方。每個Git對象都有一個唯一的SHA-1哈希值，用于標(biāo)識該對象。這個哈希值是根據(jù)對象的內(nèi)容計算得到的，因此即使是內(nèi)容微小的改動也會生成一個完全不同的哈希值。

4. 更新暫存區(qū)的索引：同時，git add 命令也會更新暫存區(qū)的索引，以便記錄哪些文件被修改了，以及它們的最新哈希值。暫存區(qū)實際上存儲了文件內(nèi)容的哈希值和路徑信息，用于跟蹤文件的修改狀態(tài)。

通過以上步驟，git add 命令將工作區(qū)中的修改內(nèi)容轉(zhuǎn)化為Git對象，并將這些對象添加到暫存區(qū)中，以便后續(xù)提交到版本庫中。

至于版本庫的版本控制，實際上是通過維護(hù)對象庫來實現(xiàn)的。

版本庫的版本控制原理：

• Git的版本控制實際上是通過對象庫來實現(xiàn)的。對象庫中的每一個對象代表著項目的一個文件或目錄的狀態(tài)。在Git中，有四種類型的對象：blob對象（文件內(nèi)容）、tree對象（目錄結(jié)構(gòu)）、commit對象（提交信息）和tag對象（標(biāo)簽）。
• 當(dāng)我們對工作區(qū)的文件進(jìn)行修改并執(zhí)行 git add 命令后，Git會將修改的文件內(nèi)容寫入到對象庫中，并生成一個新的blob對象。同時，Git會更新暫存區(qū)的索引，將文件名和新生成的blob對象關(guān)聯(lián)起來。
• 當(dāng)我們執(zhí)行 git commit 命令時，Git會根據(jù)暫存區(qū)的索引創(chuàng)建一個新的commit對象，其中包含了提交的作者、提交時間、提交信息等元數(shù)據(jù)，并指向暫存區(qū)的目錄結(jié)構(gòu)。這個目錄結(jié)構(gòu)實際上是一個tree對象，它記錄了當(dāng)前提交時項目文件的狀態(tài)。
• 最后，Git會將新生成的commit對象加入到版本庫的分支中，例如master分支，同時更新分支指針，使其指向最新的提交，以反映項目的最新狀態(tài)。

總的來說，Git的版本控制是通過對象庫中的對象來實現(xiàn)的，每個對象代表了項目的一個狀態(tài)或操作記錄。通過不同類型的對象，Git能夠跟蹤和管理項目的所有歷史記錄，并提供強大的版本控制功能。同時，暫存區(qū)則是起到了一個中間狀態(tài)的作用，幫助我們管理和提交工作區(qū)的修改。

另外，回顧我們打印出來的目錄樹，HEAD、objects，都存放在.git/目錄樹下。暫存區(qū)其實也在，它放在index中，沒被打印出來是因為我們之前還沒有進(jìn)行任何add操作。

• HEAD：HEAD 是一個指向當(dāng)前分支的符號引用（Symbolic Reference），它實際上是一個指向目前所在分支的引用。在Git中，HEAD 始終指向當(dāng)前所在的分支，或者在提交前指向即將提交的分支。通過 HEAD，Git 知道當(dāng)前所在的分支，便于我們進(jìn)行代碼的提交、分支切換等操作。
• objects：objects 目錄是Git對象庫，它存儲了Git中的所有對象，包括提交對象（commit）、樹對象（tree）、標(biāo)簽對象（tag）以及文件內(nèi)容對象（blob）。在Git中，一切皆為對象，每個對象都有自己的唯一哈希值來標(biāo)識。這個目錄中的對象組織形式復(fù)雜，通常我們無需直接操作它，而是通過Git命令來管理和訪問對象。
• index：index 是暫存區(qū)的索引，它記錄了即將提交到版本庫的文件狀態(tài)信息，包括文件的修改狀態(tài)、路徑信息以及文件的哈希值等。暫存區(qū)實際上是一個二進(jìn)制文件，位于 .git 目錄下的 index 文件中。在進(jìn)行 git add 操作后，工作區(qū)的修改會被添加到暫存區(qū)中，暫存區(qū)的內(nèi)容會在之后的提交操作中被寫入版本庫。

這些目錄和文件的存在使得Git能夠有效地進(jìn)行版本控制和文件管理。通過將文件的修改和提交狀態(tài)記錄在這些文件中，Git可以跟蹤文件的變化、管理版本歷史，并支持多人協(xié)作開發(fā)。雖然這些目錄和文件在平時的使用中不太直觀，但它們是Git的核心組成部分，為Git的功能提供了基礎(chǔ)支持。

添加文件

在包含?.git 的目錄下新建一個 ReadMe 文件后（touch Readme），我們可以使用 git add 命令將文件添加到暫存區(qū)，以準(zhǔn)備進(jìn)行提交到本地倉庫。下面是幾種常見的 git add 命令用法：

1. 添加一個或多個文件到暫存區(qū)：

   git add [file1] [file2] ...

   這條命令將指定的一個或多個文件添加到暫存區(qū)，以便之后提交到版本庫。

2. 添加指定目錄到暫存區(qū)，包括子目錄：

   git add [dir]

   這條命令將指定目錄及其子目錄下的所有文件添加到暫存區(qū)。

3. 添加當(dāng)前目錄下的所有文件改動到暫存區(qū)：

   git add .

   這條命令將當(dāng)前目錄下的所有文件改動（包括新增、修改和刪除）都添加到暫存區(qū)。

添加到暫存區(qū)后，我們可以使用 git commit 命令將暫存區(qū)的內(nèi)容提交到本地倉庫中。常見的 git commit 命令用法包括：

1. 提交暫存區(qū)全部內(nèi)容到本地倉庫中，并添加提交描述信息：

   git commit -m "message"

   這條命令將暫存區(qū)中的所有修改內(nèi)容提交到本地倉庫，并附帶一個提交描述信息，用于記錄本次提交的目的和細(xì)節(jié)。

2. 提交暫存區(qū)的指定文件到倉庫區(qū)，并添加提交描述信息：

   git commit [file1] [file2] ... -m "message"

   這條命令將暫存區(qū)中指定的文件提交到本地倉庫中，并附帶一個提交描述信息。

需要注意的是，在使用 git commit 命令時，后面的 -m 選項必須跟上本次提交的描述信息，這部分內(nèi)容絕對不能省略。提交描述信息是用來記錄我們的提交細(xì)節(jié)，對于其他團(tuán)隊成員或自己日后查看版本歷史十分重要。因此，描述信息要清晰明了，準(zhǔn)確地描述本次提交所做的修改或新增。

當(dāng)成功執(zhí)行 git commit 命令后，Git 會提供一些反饋信息，通常會告訴我們有幾個文件被修改以及修改了多少行內(nèi)容。例如，它可能會顯示：“1 file changed”（1個文件被改動），“2 insertions”（插入了兩行內(nèi)容），這意味著我們新添加的 ReadMe 文件被成功提交到了本地倉庫，并且其中的內(nèi)容變動已經(jīng)被記錄下來。

在Git中，我們可以多次使用 git add 命令來添加不同的文件到暫存區(qū)，但只需執(zhí)行一次 git commit 命令就可以將暫存區(qū)中所有的修改一次性提交到本地倉庫。這是因為在我們執(zhí)行 git add 命令時，需要提交的文件都被添加到了暫存區(qū)中，而后續(xù)的 git commit 命令會將暫存區(qū)的所有修改都一并提交。這種機制使得我們可以更加靈活地管理和提交文件，無需每次修改都進(jìn)行一次提交操作，同時確保了提交的一致性和完整性。

截止目前為止，我們已經(jīng)成功將代碼提交到了本地倉庫?，F(xiàn)在，我們可以使用 git log 命令來查看提交的歷史記錄。該命令會顯示從最近到最遠(yuǎn)的提交日志，并且可以看到每次提交時的日志消息。

如果覺得輸出的信息太多，導(dǎo)致眼花繚亂，可以嘗試添加 --pretty=oneline 參數(shù)，這樣輸出的每條提交記錄就會以一行的形式顯示，更加簡潔清晰。

需要說明的是，我們在 git log 中看到的一大串類似 23807c5...56eed6 的是每次提交的 commit id（版本號）。Git 的 commit id 不是簡單的遞增數(shù)字，而是通過 SHA1 計算得到的一個非常大的十六進(jìn)制數(shù)字，用于唯一標(biāo)識每次提交。每個人的 commit id 都是不同的，因此你\大家看到的 commit id 和我看到的肯定是不同的，以你們自己的為準(zhǔn)。通過 commit id，我們可以在需要的時候精準(zhǔn)地回溯到某次提交，查看具體的修改內(nèi)容和提交信息。

查看 .git 文件

重開一個窗口，來看看我們新的的 .git 的目錄結(jié)構(gòu)（假設(shè)我們目前只提交了一個文件Readme）：

在執(zhí)行了 git add 命令之后，目錄結(jié)構(gòu)發(fā)生了變化。我們可以看到 .git/ 目錄下新增了一些文件和目錄：

• COMMIT_EDITMSG：這是一個臨時文件，用于存放即將提交的修改的編輯消息。
• index：這是暫存區(qū)（也稱為索引）的文件，它存儲了當(dāng)前暫存區(qū)的狀態(tài)，包含了即將提交的修改的信息。
• logs 目錄：包含了提交日志的信息，其中 HEAD 目錄下存放了當(dāng)前分支的提交歷史，refs/heads/master 目錄下存放了 master 分支的提交歷史。
• objects 目錄：這是對象庫，用于存儲 Git 對象。Git 對象是通過 SHA1 計算生成的哈希值來標(biāo)識的文件和目錄，這些對象包含了文件內(nèi)容、目錄結(jié)構(gòu)等信息。
• refs 目錄：這是引用目錄，存放了 Git 中的引用信息，如分支和標(biāo)簽。在 heads 子目錄下存放了分支的引用信息，而在 tags 子目錄下存放了標(biāo)簽的引用信息。

這些變化反映了我們執(zhí)行 git add 命令后的操作：將工作區(qū)的修改添加到了暫存區(qū)中，并提交到本地倉庫。這些文件和目錄的生成和變化是 Git 內(nèi)部進(jìn)行版本控制所必需的，它們幫助 Git 跟蹤、管理和記錄我們的項目歷史和修改。

我們還需要驗證一下HEAD指針究竟指向哪里：

也就是這個部分：

?

我們再來看一下master里面存放著什么：

?

你會發(fā)現(xiàn)這就是我們最新一次提交的commit的ID：

在對象庫里其實也就對應(yīng)著：

?

那么我們怎么查看對象里面的具體內(nèi)容呢？

我們可以得到以下信息：

1. tree 行指示了當(dāng)前提交所對應(yīng)的樹對象的哈希值（commit id）為 d8bf841c208ac376458fe45cac34d82c12c6bcfa。這表明此次提交涉及的所有文件和目錄結(jié)構(gòu)都在這個樹對象中。
2. author 行顯示了提交的作者信息，包括作者的名稱和電子郵件地址，以及提交時的時間戳。
3. committer 行顯示了提交的提交者信息，包括提交者的名稱和電子郵件地址，以及提交時的時間戳。
4. 在這個例子中，提交消息為 "add File1"，表示此次提交添加了一個名為 "File1" 的文件。

綜合起來，這個輸出顯示了提交對象的詳細(xì)信息，包括提交涉及的樹對象、作者、提交者以及提交消息等。

我們可以再打開它給出的這個對象看看內(nèi)容：

我們執(zhí)行了 git cat-file -p d8bf841c208ac376458fe45cac34d82c12c6bcfa 命令，顯示了樹對象 d8bf841c208ac376458fe45cac34d82c12c6bcfa 的內(nèi)容。該樹對象包含了一個文件條目，其文件模式為 100644，對象類型為 blob，哈希值為 6972ae3dc63ccc7e528ccfdb9b88b33b023c4da1，文件名為 Readme

我們又通過 git cat-file -p 6972ae3dc63ccc7e528ccfdb9b88b33b023c4da1 命令查看了哈希值為 6972ae3dc63ccc7e528ccfdb9b88b33b023c4da1 的 blob 對象的內(nèi)容。該對象包含兩行文本內(nèi)容，分別為 "Hey~~~" 和 "Long time no see!!!"。

所以，通過這些命令我們可以查看提交對象、樹對象以及 blob 對象的詳細(xì)信息，以及它們之間的關(guān)聯(lián)。

我們總結(jié)一下：

1. Index (暫存區(qū))

• 概念： Index 是 Git 中的一個重要概念，也稱為暫存區(qū)或者緩存區(qū)。它是一個存放在 .git 目錄下的文件，用于暫時存放將要提交到版本庫的修改。
• 作用： 當(dāng)我們使用 git add 命令將文件添加到 Index 后，Git 會將這些文件的快照放入暫存區(qū)。這意味著這些文件的最新狀態(tài)已經(jīng)被記錄并準(zhǔn)備好被提交。
• 操作方式： 通過 git add 命令可以將工作區(qū)的修改添加到 Index 中，使其成為下一次提交的一部分。

2. HEAD

• 概念： HEAD 是 Git 中的一個指針，它指向當(dāng)前所在的分支（或者某個具體的提交）。通常情況下，它指向默認(rèn)分支，如 master 分支。
• 默認(rèn)指向 master 分支的指針： 當(dāng)我們初始化一個新的 Git 倉庫時，master 分支是默認(rèn)存在的，而 HEAD 則指向這個 master 分支。
• 保存的是當(dāng)前最新的 commit id： HEAD 指向的位置存儲的是當(dāng)前所在分支的最新提交的 commit id。

3. Objects (對象庫)

• 概念： 在 Git 中，objects 是用來存儲版本庫對象的地方。這些對象包括提交（commit）、樹（tree）、標(biāo)簽（tag）等，它們的內(nèi)容以及文件狀態(tài)都被存儲在 objects 中。
• 存儲位置： objects 目錄位于 .git 目錄下，用來存儲各種版本庫對象及其內(nèi)容。
• 對象的創(chuàng)建和更新： 當(dāng)執(zhí)行?git add 命令時，會將工作區(qū)修改的文件內(nèi)容寫入一個新的對象中，并更新暫存區(qū)的目錄樹。這個新對象會被存儲在 objects 目錄下。
• 對象查找： Git 使用 SHA-1 哈希算法來給每個對象一個唯一的標(biāo)識符。當(dāng)需要查找某個對象時，需要使用對象的哈希值（commit id）。這個哈希值的前兩位作為目錄名，后38位作為文件名，以此來查找對象文件。
• 查看對象內(nèi)容： 一般情況下，對象文件是經(jīng)過 SHA-1 加密的，無法直接查看其內(nèi)容。但可以使用 git cat-file 命令來查看版本庫對象的內(nèi)容。

在學(xué)習(xí)的過程中，建議將常見的 Git 操作與 .git 目錄中的結(jié)構(gòu)內(nèi)容變化相聯(lián)系起來。這樣做有助于我們更好地理解 Git 的詳細(xì)流程。而且，隨著我們繼續(xù)學(xué)習(xí)，我們將探討更多關(guān)于分支、標(biāo)簽等內(nèi)容，因此后續(xù)的學(xué)習(xí)將會更加深入和有意義。對這些內(nèi)容的深入研究將使我們對 Git 的工作原理有更清晰的認(rèn)識，為我們更高效地使用 Git 提供了重要的基礎(chǔ)。?

修改文件

在 Git 中，跟蹤并管理的是修改而不是文件，這一設(shè)計使得 Git 在版本控制系統(tǒng)中具有獨特的優(yōu)勢。那么什么是修改呢？修改指的是對文件內(nèi)容的任何更改，無論是添加、刪除、修改、移動還是重命名等操作都被視為一個修改。以下是對修改的一些具體示例：

1. 新增一行內(nèi)容： 在文件中添加一行文字或代碼，這被視為一個修改。

2. 刪除一行內(nèi)容： 從文件中移除一行文字或代碼，這也是一個修改。

3. 更改某些字符： 修改文件中的某些字符，比如更改代碼中的變量名或修正拼寫錯誤，都屬于修改的范疇。

4. 刪除一些內(nèi)容并添加一些內(nèi)容： 同時進(jìn)行刪除和添加操作，比如刪除一段代碼并替換為新的代碼，這也被視為一個修改。

5. 創(chuàng)建一個新文件： 在版本庫中新增一個文件，這同樣被認(rèn)為是一個修改，因為它改變了版本庫的狀態(tài)。

在 Git 中，每次修改都被記錄下來，并且以一種高效的方式存儲和管理。通過跟蹤修改而不是文件本身，Git 能夠更準(zhǔn)確地追蹤文件的變化歷史，并且可以更有效地處理大型項目中的文件重命名、移動和合并等操作。這也是 Git 在版本控制領(lǐng)域中被廣泛使用的一個重要原因之一。

我們現(xiàn)在就對Readme進(jìn)行一次修改：

此時，倉庫中的 Readme 和我們工作區(qū)的 Readme 是不同的，何查看當(dāng)前倉庫的狀態(tài)呢？
在 Git 中，要查看當(dāng)前倉庫的狀態(tài)，即了解工作區(qū)和暫存區(qū)的狀態(tài)差異，可以使用 git status 命令。

執(zhí)行 git status 命令后，Git 會顯示出當(dāng)前倉庫中所有文件的狀態(tài)信息，包括：

• 哪些文件已修改但尚未添加到暫存區(qū)（工作區(qū)修改）。
• 哪些文件已經(jīng)添加到暫存區(qū)但尚未提交（暫存區(qū)修改）。
• 是否存在需要提交的文件，或者是否工作區(qū)干凈（沒有未跟蹤或未修改的文件）。

?

根據(jù)提供的 git status 輸出，可以看出當(dāng)前倉庫中的 Readme 文件已被修改，但尚未添加到暫存區(qū)。在輸出中，Git 提示了兩個重要的信息：

• Changes not staged for commit： 這部分指示了有哪些修改還未被添加到暫存區(qū)，即工作區(qū)中的修改。
• no changes added to commit： 這部分指示了尚未添加任何修改到暫存區(qū)，因此還沒有準(zhǔn)備好提交。

目前，我們只知道文件被修改了，如果能知道具體哪些地方被修改了，就更好了。

git diff 命令是非常有用的工具，可以用來顯示工作區(qū)和暫存區(qū)之間、或者版本庫和工作區(qū)之間的文件差異。使用 git diff 命令可以幫助你具體了解文件的修改情況，包括哪些地方被修改了以及修改的具體內(nèi)容。

顯示工作區(qū)和暫存區(qū)之間的差異：

git diff [file]

這會顯示指定文件在工作區(qū)和暫存區(qū)之間的差異，包括哪些地方被修改了以及修改的具體內(nèi)容。

顯示版本庫和工作區(qū)之間的差異：

git diff HEAD -- [file]

這會顯示指定文件在版本庫和工作區(qū)之間的差異，即你當(dāng)前工作的分支（通常是 master 分支）和工作目錄中文件之間的差異。

git diff 命令顯示的差異信息格式與 Unix 通用的 diff 格式一致。這種格式通常包含了修改的上下文信息以及具體的變更內(nèi)容。一般來說，每個修改都以一個描述性的標(biāo)記開頭，例如：

• + 表示新增的內(nèi)容。
• - 表示刪除的內(nèi)容。
• @@ 表示上下文信息，標(biāo)識了修改的位置。

由此，我們可以得到剛剛打印出來的信息：

1. diff --git a/Readme b/Readme：這一行指示了文件的路徑和名稱，a/Readme 表示舊文件，b/Readme 表示新文件。
2. index 6972ae3..1139197 100644：這一行顯示了文件索引信息，其中 6972ae3 是舊文件的索引，1139197 是新文件的索引。100644 表示文件的權(quán)限和類型。
3. --- a/Readme 和 +++ b/Readme：這兩行指示了舊文件和新文件的路徑和名稱。
4. @@ -1,2 +1,3 @@：這一行提供了修改的上下文信息。-1,2 表示舊文件中從第 1 行開始的連續(xù) 2 行內(nèi)容，+1,3 表示新文件中從第 1 行開始的連續(xù) 3 行內(nèi)容。
5. Hey~~~ 和 Long time no see!!!：這兩行是舊文件中的內(nèi)容，表示被修改之前的內(nèi)容。
6. +This is the first change~：這一行是新文件中的內(nèi)容，表示新增的內(nèi)容。根據(jù) + 符號，可以看出這是一個新增的行，內(nèi)容是 This is the first change~。

知道了對 ReadMe 做了什么修改后，再把它提交到本地倉庫就放心多了。

• Changes to be committed：這一行表明有一些修改已經(jīng)被添加到了暫存區(qū)，即這些修改已經(jīng)準(zhǔn)備好被提交到版本庫中。
• (use "git restore --staged <file>..." to unstage)：這是一個提醒，告訴我們?nèi)绻枰∠麜捍鎱^(qū)的修改，可以使用 git restore --staged <file> 命令來將文件恢復(fù)到未暫存的狀態(tài)。

版本回退

在Git中，版本回退是一項重要的功能，它允許我們將代碼庫中的狀態(tài)恢復(fù)到歷史上的某個特定版本。當(dāng)我們發(fā)現(xiàn)之前的工作出現(xiàn)了嚴(yán)重的問題，或者需要重新開始某個特定的歷史版本時，版本回退功能就變得至關(guān)重要了。而git reset命令正是用于實現(xiàn)版本回退的關(guān)鍵命令。

通過執(zhí)行g(shù)it reset命令，就可以將當(dāng)前的工作區(qū)、暫存區(qū)以及版本庫中的狀態(tài)回退到我們指定的某個提交版本。這個提交版本可以是通過提交號、分支名、相對于當(dāng)前版本的偏移量等方式指定。

git reset命令的基本語法格式如下：

git reset [--soft | --mixed | --hard] [commit]

當(dāng)執(zhí)行 git reset 命令用于版本回退時，其本質(zhì)是將版本庫中的內(nèi)容進(jìn)行回退。

具體回退到哪個版本以及是否影響工作區(qū)或暫存區(qū)的內(nèi)容則由命令參數(shù)決定：

• --mixed：默認(rèn)選項，可以省略參數(shù)。該參數(shù)將暫存區(qū)的內(nèi)容回退為指定提交版本的內(nèi)容，但工作區(qū)的文件保持不變。換句話說，這個選項會將暫存區(qū)的狀態(tài)回退到指定版本，但不會影響工作區(qū)的文件。這意味著，工作區(qū)中的文件保持未變化，我們需要手動撤銷或修改工作區(qū)中的文件。
• --soft：這個參數(shù)對工作區(qū)和暫存區(qū)的內(nèi)容都不做改變，只是將版本庫回退到某個指定版本。換句話說，暫存區(qū)和工作區(qū)的內(nèi)容保持不變，只有版本庫中的指針移動到了指定的提交版本。因此，使用這個參數(shù)可以讓我們“虛擬”地回到過去的某個版本，而不會影響當(dāng)前的工作區(qū)和暫存區(qū)。
• --hard：這個參數(shù)會將暫存區(qū)和工作區(qū)都回退到指定版本。使用這個參數(shù)時需要格外小心，因為它會丟棄暫存區(qū)和工作區(qū)中的所有變更，將它們都恢復(fù)到指定版本的狀態(tài)。如果工作區(qū)中有未提交的代碼修改，執(zhí)行這個命令后這些修改都將丟失。因此，在使用這個參數(shù)時要非常慎重，確保不會丟失重要的工作。

HEAD 說明：

• HEAD 可以直接指定為 commit id，表示要回退到的具體提交版本。
• HEAD 表示當(dāng)前版本。
• HEAD^ 表示上一個版本。
• HEAD^^ 表示上上一個版本。
• 以此類推...

數(shù)字表達(dá)式：
可以使用數(shù)字來表示相對于當(dāng)前版本的偏移量。

• HEAD~0 表示當(dāng)前版本。
• HEAD~1 表示上一個版本。
• HEAD^2 表示上上一個版本。
• 以此類推...

總之，git reset 命令是一個強大的工具，允許我們在需要時回退到任何一個歷史版本，但需要根據(jù)具體情況選擇合適的參數(shù)以及版本，以避免意外丟失工作成果。

那么如果我們回退完成之后又后悔了咋辦？

?

在我們的操作中，我們通過 git reset --hard 命令將 HEAD 指針移動到了之前的某個特定的提交版本，這個版本就是我們指定的 commit id。在第一次使用 git reset --hard 命令時，我們將 HEAD 指針移動到了 ff1e0bb3153ae267f9249567a057e1520383a3bc 這個提交版本，這是我們指定的歷史版本。

然后，我們再次使用 git reset --hard 命令將 HEAD 指針移動到了另一個提交版本 93bca23be22103a1ce0c57ec75d253658ace91e1。這意味著我們又將 HEAD 指針重新指向了另一個歷史版本。

通過這兩次 git reset --hard 操作，我們實際上是在版本歷史中來回移動 HEAD 指針，指向不同的提交版本。這種操作并不是將版本庫中的內(nèi)容進(jìn)行恢復(fù)，而是在版本控制系統(tǒng)中移動 HEAD 指針，以指向不同的歷史版本，因此我們可以多次進(jìn)行版本回退。

那么如果我們回退之后不小心把服務(wù)器關(guān)了，或者屏幕清了：

?

此時我們怎么“吃后悔藥”呢？

git reflog 是 Git 中的一個命令，用于查看本地倉庫的引用日志（reference logs）。引用日志記錄了本地倉庫中 HEAD 和分支的移動歷史，即使在重置或回退后，也可以通過引用日志找到之前的提交狀態(tài)。

• 引用日志是什么？引用日志是 Git 中的一種記錄機制，用于追蹤本地倉庫的引用（如 HEAD、分支、標(biāo)簽等）的移動歷史。每次引用發(fā)生變化時，Git 將會更新引用日志。
• 引用日志中包含的信息：引用日志會顯示每次引用變動的提交哈希（commit hash）、引用（如 HEAD、分支名）、變動操作（如提交、分支切換）、時間戳等信息。
• 引用日志的作用：引用日志可以幫助我們查找歷史操作記錄，特別是在執(zhí)行了諸如重置（reset）、回退（checkout）、合并（merge）等改變分支狀態(tài)的操作后，可以使用引用日志找回之前的狀態(tài)。

注意事項：

• 引用日志只在本地存在，不會被推送到遠(yuǎn)程倉庫中。
• 引用日志中的信息并不是永久保存的，會隨著時間和 Git 命令的執(zhí)行而被覆蓋。

通過使用 git reflog，我們可以更好地理解和管理本地倉庫的引用狀態(tài)，同時在需要時進(jìn)行版本恢復(fù)或調(diào)整。

?

我們照樣可以使用commitID的一部分進(jìn)行回退：

?

再次強調(diào)，Git 版本回退的速度之所以如此迅速，是因為 Git 在內(nèi)部維護(hù)了一個指向當(dāng)前分支（通常是 master 分支）的 HEAD 指針，并且保存了當(dāng)前 master 分支的最新提交的 commit id 在 refs/heads/master 文件中。因此，當(dāng)我們執(zhí)行版本回退操作時，Git 實際上只需修改 refs/heads/master 文件，將其指向特定的提交版本即可，而無需對整個倉庫的文件進(jìn)行復(fù)雜的操作。這種簡潔高效的機制使得 Git 能夠在瞬間完成版本回退，讓開發(fā)人員能夠快速、輕松地管理代碼歷史。

撤銷修改

如果我們在工作區(qū)寫了很長時間的代碼，但又覺得寫的代碼實在是很不理想，想要恢復(fù)到上一個版本。

情況一：對于工作區(qū)的代碼，還沒有 add

我們先對Readme文件進(jìn)行一些修改：

?此時想要撤銷這次修改，當(dāng)然可以使用 vim 命令直接編輯我們的文件內(nèi)容。

然而，如果我們已經(jīng)寫了很長時間的代碼，但尚未進(jìn)行提交，要撤銷這些修改就變得更加困難，因為我們可能已經(jīng)忘記了我們到底修改了哪些內(nèi)容。在這種情況下，我們可以使用 git checkout -- [file] 命令來讓工作區(qū)的文件回到最近一次添加或提交時的狀態(tài)。

具體而言，git checkout -- [file] 命令會將指定文件恢復(fù)到最近一次添加或提交時的狀態(tài)，丟棄工作區(qū)中的任何未提交修改。這樣可以避免手動編輯文件或使用 git diff 命令查看差異并手動刪除，節(jié)省了時間和精力。

需要注意的是，git checkout -- [file] 命令中的雙橫線 -- 非常重要，不能省略。因為如果省略了雙橫線，這個命令就會變成另外一個意思，可能會產(chǎn)生意想不到的結(jié)果。

因此，通過使用 git checkout -- [file] 命令，我們可以快速、高效地撤銷工作區(qū)中未提交的修改，不需要手動比較和刪除代碼，避免了潛在的錯誤和麻煩。

情況二：已經(jīng) add ，但沒有 commit

add 后還是保存到了暫存區(qū)呢？怎么撤銷呢？

讓我們來回憶一下學(xué)過的 git reset 回退命令：
git reset 是一個用于回退版本的重要命令。當(dāng)使用 git reset --mixed 參數(shù)時，它可以將暫存區(qū)的內(nèi)容退回到指定的版本內(nèi)容，同時保持工作區(qū)文件不變（此時就回到了我們的情況一）。當(dāng)然，也可以選擇 --hard 參數(shù)對工作區(qū)和暫存區(qū)同時進(jìn)行回退。

另外，git reset 還可以用來回退到當(dāng)前版本。

具體來說：

1. 使用 git reset --mixed <commit> 命令可以將暫存區(qū)的內(nèi)容退回到指定的 <commit> 版本內(nèi)容，但工作區(qū)的文件不會受到影響。這意味著，指定版本之后的修改內(nèi)容會被移動到工作區(qū)，并保留在未暫存的狀態(tài)下。
2. 另外，如果我們想回退到當(dāng)前版本（也就是和版本庫保持一致的版本），可以使用 git reset --mixed HEAD 命令。這將取消暫存區(qū)的所有內(nèi)容，并將它們移動到工作區(qū)，但不會影響工作區(qū)的文件。這樣可以撤銷暫存區(qū)的所有更改，讓我們重新開始添加和提交更改。

?

情況三：已經(jīng) add ，并且也 commit 了?

同理，我們可以使用 git reset --hard HEAD^ 命令來回退到上一個版本的情景。這個命令會將當(dāng)前分支的 HEAD 指針移動到上一個提交，同時將工作區(qū)和暫存區(qū)的內(nèi)容都回退到上一個版本。

但是，這種回退方式有一個重要的前提條件：我們的本地版本庫尚未推送到遠(yuǎn)程版本庫。

由于Git是一種分布式版本控制系統(tǒng)，每個開發(fā)者都有自己的本地版本庫，而遠(yuǎn)程版本庫是共享的中央倉庫。

如果我們已經(jīng)將我們的本地提交push推送到遠(yuǎn)程版本庫，并且其他開發(fā)者也已經(jīng)在遠(yuǎn)程版本庫中工作了，那么使用 git reset --hard 命令將會帶來一些問題：

• 我們的本地工作將會被徹底覆蓋，所有未提交的修改都將丟失。
• 如果我們嘗試將這些丟失的提交推送到遠(yuǎn)程版本庫，可能會導(dǎo)致合并沖突和代碼丟失。

因此，在使用 git reset --hard 命令時，務(wù)必確保我們的本地提交尚未推送到遠(yuǎn)程版本庫，以免造成不可挽回的損失。

刪除文件

在 Git 中，刪除也是一個修改操作，我們實戰(zhàn)一下。

如果要刪除 file1?文件，怎么做？

但是這只是對工作區(qū)中的文件進(jìn)行了刪除：

?

此時，工作區(qū)和版本庫已經(jīng)不一致了，因為我們只刪除了工作區(qū)的文件，而版本庫中的文件仍然存在。如果要徹底刪除文件，需要同時清除工作區(qū)和版本庫中的文件。

為了完成這個任務(wù)，我們可以使用 git rm 命令將文件從暫存區(qū)和工作區(qū)中刪除，并且隨后運行 git commit -m "Remove [file]" 命令，提交刪除操作，以記錄這一變更。

還有一種更簡略的命令方式：

?

git rm 命令可以更簡便地完成刪除文件的操作，而不需要分成兩步驟。

分支管理

理解分支

紹 Git 的殺手級功能之一就是分支。

我們通過一個簡單的例子來理解一下什么是分支。

當(dāng)你在做一次旅行計劃時，你可以將每個目的地看作是旅行計劃的一個分支。

假設(shè)你計劃進(jìn)行一次穿越歐洲的旅行。你的旅行計劃可能包括巴黎、倫敦和羅馬等多個目的地。你可以將每個目的地看作是旅行計劃的一個分支。

• 分支就像旅行目的地：每個分支就像是旅行計劃中的一個目的地，你可以在每個目的地停留一段時間，探索當(dāng)?shù)氐娘L(fēng)土人情和景點。就像旅行中選擇不同的目的地一樣，每個分支都代表了旅行計劃中的一個獨立部分。
• 互不干擾的探索：當(dāng)你在巴黎的分支上計劃行程時，你的行程安排和計劃只會影響到巴黎這個目的地的探索，而不會影響其他目的地。同樣地，當(dāng)你在倫敦的分支上計劃行程時，你的活動也只會影響到倫敦這個目的地。
• 分支合并：然而，在某個時刻，當(dāng)你已經(jīng)完成了每個目的地的探索后，你可能會將這些分支合并在一起，形成整個旅行計劃。這就像是將不同的目的地合并成一個完整的旅行計劃。在合并后，你會發(fā)現(xiàn)自己已經(jīng)完成了一次穿越歐洲的旅行，而每個目的地的探索成果都匯聚在了一起，這就是分支合并的結(jié)果。

在版本回退的概念中，我們已經(jīng)了解到，每次在Git中進(jìn)行提交操作時，Git會將這些提交串聯(lián)起來形成一個時間線，這個時間線可以被理解為一個分支。目前為止，我們只有一條時間線，在Git中，這個分支被稱為主分支，即master分支。

1. 理解主分支（master）：主分支（master）是Git中的默認(rèn)分支，它是版本控制歷史的主要線索。所有的提交都沿著主分支進(jìn)行，形成一個線性的歷史記錄。在開始項目時，通常會在主分支上進(jìn)行開發(fā)和提交。

2. 理解HEAD指針：嚴(yán)格來說，HEAD指針并不直接指向提交，而是指向當(dāng)前分支。也就是說，HEAD指針指向當(dāng)前活動的分支，而該分支則指向最新的提交。因此，當(dāng)我們在Git中查看HEAD時，我們實際上是在查看當(dāng)前所在的分支。

3. 主分支的移動：每次進(jìn)行提交操作，主分支（master）都會向前移動一步，指向最新的提交。這意味著隨著我們不斷地進(jìn)行提交，主分支的線性歷史記錄也會不斷地延長。而HEAD指針則會隨著主分支的移動而保持指向當(dāng)前分支的位置，這樣即使主分支在提交后移動，HEAD也會跟隨著當(dāng)前分支移動。

?

通過查看當(dāng)前的版本庫，我們也能清晰的理出思路：

?

創(chuàng)建分支

Git 支持我們查看或創(chuàng)建其他分支。

首先我們可以看看當(dāng)前倉庫中有哪些本地分支：

需要明確的一點就是，除了指向主分支master之外，HEAD也可以指向其他分支，被指向的分支就是當(dāng)前正在工作的分支。

這意味著我們可以在不同的分支之間切換，使得我們可以在不同的工作環(huán)境中進(jìn)行開發(fā)，并且保持每個分支的獨立性。例如，我們可以在開發(fā)一個新功能時切換到一個專門的功能分支，完成后再切換回主分支進(jìn)行合并操作。通過這種方式，我們可以更加靈活地管理我們的項目，并且更好地控制版本和功能的開發(fā)進(jìn)度。

在這里，我們來創(chuàng)建第一個自己的分支，命名為 dev。創(chuàng)建新分支的命令如下：

創(chuàng)建新的分支后，Git會新建一個指針，稱為dev，此時的 * 號表示當(dāng)前HEAD指向的分支是主分支master。

此外，通過目錄結(jié)構(gòu)可以發(fā)現(xiàn)，新的dev分支已經(jīng)創(chuàng)建：

而且可以觀察到，目前dev和master指向了相同的提交記錄。

切換分支

那如何切換到 dev 分支下進(jìn)行開發(fā)呢？

使用 git checkout 命令即可完成切換：

注意，我們先前強調(diào)過 git checkout進(jìn)行回退操作的時候一定要加上“ -- ”，現(xiàn)在你可以理解了。

在 Git 中，git checkout 命令有多種用法，省略了 -- 時，Git 可能會將 [file] 解釋為分支名、提交哈希值或者其他引用，而不是文件名。

比如我們現(xiàn)在執(zhí)行 git checkout [branch]，Git 將會切換到指定的分支，并將工作區(qū)和暫存區(qū)的內(nèi)容更新為該分支的最新狀態(tài)。

?接下來，在 dev 分支下修改 ReadMe 文件，新增一行內(nèi)容，并進(jìn)行一次提交操作：

現(xiàn)在再切換回master分支：

切換回 master 分?后，發(fā)現(xiàn)ReadMe?件中新增的內(nèi)容不見了?。。?/p>

在 dev 分支上，內(nèi)容還在。為什么會出現(xiàn)這個現(xiàn)象呢？我們來看看 dev 分支和 master 分支指向，發(fā)現(xiàn)兩者指向的提交是不?樣的：

?

合并分支

為了在 master 主分支上能看到新的提交，就需要將 dev 分支合并到 master 分支：

git merge 命令用于合并指定分支到當(dāng)前分支。通過合并分支，我們可以將不同分支的工作成果整合在一起，使得項目的功能得以完善和增強。合并分支時，Git會嘗試將兩個分支的更改合并到一起，并解決任何可能的沖突。最終，合并操作會生成一個新的提交，其中包含了兩個分支的所有更改，這樣我們就可以在當(dāng)前分支上繼續(xù)開發(fā)和工作。

"Fast-forward" 是 Git 在執(zhí)行合并操作時的一種情況，表示當(dāng)前分支可以簡單地移動到要合并的分支的最新提交，而無需進(jìn)行實際的合并操作。

具體來說，當(dāng)我們執(zhí)行 git merge 命令時，如果要合并的分支是當(dāng)前分支的直接上游（即當(dāng)前分支是要合并的分支的祖先），并且沒有新的提交產(chǎn)生，那么 Git 就會執(zhí)行 "Fast-forward" 合并。這種情況下，Git 只需要將當(dāng)前分支移動到要合并分支的最新提交，從而完成合并操作。

刪除分支

合并完成后, dev 分?對于我們來說就沒?了， 那么dev分支就可以被刪除掉，注意如果當(dāng)前正處于這個要被刪除的分支下，就不能刪除當(dāng)前分支：

可以在其他分支下刪除當(dāng)前分支：

?

因為創(chuàng)建、合并和刪除分支在Git中都非常迅速，所以Git鼓勵你使用分支來完成某個任務(wù)，然后在合并后再刪除分支。這種做法與直接在主分支（master）上工作的效果是一樣的，但是使用分支的方式更為安全。

綜上，我們總結(jié)一下整個流程：

1. 創(chuàng)建分支： 首先，我們可以創(chuàng)建一個新的分支來專門處理某個任務(wù)或功能。這樣做的好處是，我們可以在不影響主分支的情況下進(jìn)行工作，并保持主分支的穩(wěn)定性。創(chuàng)建分支的過程非?？焖?，并且不會影響其他分支或主分支的狀態(tài)。

2. 在分支上進(jìn)行工作： 接著，我們可以在新創(chuàng)建的分支上進(jìn)行工作，完成我們的任務(wù)或功能開發(fā)。在這個分支上進(jìn)行的所有提交都將僅影響到這個分支，不會對其他分支產(chǎn)生影響。這樣可以確保我們的工作在不干擾其他人或項目的情況下進(jìn)行。

3. 合并分支： 當(dāng)我們完成了任務(wù)或功能開發(fā)后，我們可以將這個分支合并回主分支。這個過程也非?？焖伲貏e是如果合并過程中沒有沖突的話。一旦合并完成，我們的工作成果就會整合到主分支中，這樣其他人也可以訪問和使用你的代碼。

4. 刪除分支： 最后，一旦我們確認(rèn)工作已經(jīng)合并到了主分支，并且不再需要這個分支了，我們就可以安全地刪除這個分支。這樣可以保持倉庫的整潔，并避免分支過多導(dǎo)致管理上的混亂。

總之，使用分支來完成任務(wù)并在合并后刪除分支是一種安全且有效的工作流程。這樣可以保持主分支的穩(wěn)定性，同時允許我們在不影響其他人或項目的情況下進(jìn)行獨立的開發(fā)工作。

合并沖突

在實際的分支合并過程中，有時候可能會遇到代碼沖突的問題。這種情況發(fā)生在兩個分支修改了同一個文件的同一部分，Git 不知道應(yīng)該保留哪一種修改，因此需要人為干預(yù)來解決沖突。

在 dev2?分支下修改 ReadMe 文件，更改文件內(nèi)容如下，并進(jìn)行一次提交：

補充一點，我們也可以使用第二種方式創(chuàng)建并直接切換到新的分支上。

切換至?master 分支，此時在 master 分支上，我們對 ReadMe 文件再進(jìn)行一次修改，并進(jìn)行提交，如下：

?

現(xiàn)在， master 分支和 dev1 分支各自都分別有新的提交，變成了這樣：

?這種情況下，Git 只能試圖把各?的修改合并起來，但這種合并就可能會有沖突：?

當(dāng)出現(xiàn)代碼沖突時，Git 會標(biāo)記出沖突的文件，并在文件中顯示沖突的部分。此時，我們需要手動編輯這些文件，解決沖突，并手動標(biāo)記哪些修改需要保留，哪些需要丟棄。解決沖突后，我們需要將文件標(biāo)記為已解決沖突，然后提交合并結(jié)果。

我們此時手動調(diào)整沖突代碼，并再次提交修正后的結(jié)果?。ㄔ俅翁峤缓苤匾?，切勿忘記！?。。?/p>

到這?沖突就解決完成，此時的狀態(tài)變成了：

?

雖然代碼沖突可能會稍微增加合并分支的復(fù)雜性，但這也是 Git 強大的一面，因為它能夠幫助我們發(fā)現(xiàn)代碼之間的潛在沖突，并促使我們及時解決。通過解決沖突，我們可以確保合并后的代碼是高質(zhì)量、可用的，從而提高項目的穩(wěn)定性和可維護(hù)性。

因此，雖然在合并分支時可能會遇到代碼沖突的問題，但通過適當(dāng)?shù)慕鉀Q方法，我們可以有效地處理這些沖突，并最終成功地合并分支，使得項目得以順利進(jìn)行。

另外，我們可以使用日志畫出當(dāng)前圖：

git log --graph --abbrev-commit命令用于查看提交歷史，并以圖形化方式展示分支與合并情況，以及每個提交的簡短哈希值。
執(zhí)行該命令后，將顯示一個圖形化的提交歷史，其中每個提交都由其哈希值表示，并且通過圖形化的方式展示了分支和合并的關(guān)系。這種圖形化的展示有助于更清晰地理解項目的版本控制歷史，以及各個分支之間的關(guān)系。

最后，不要忘記 dev2?分支使用完畢后就可以刪除了：

分支管理策略

通常情況下，當(dāng)合并分支時，如果可能，Git會采用Fast-forward模式。

還記得如果我們采用?Fast forward 模式之后，形成的合并結(jié)果是什么呢？回顧一下?：

?

在這種Fast-forward模式下，如果我們在合并后刪除了分支，查看提交歷史時會丟失分支信息，因此無法準(zhǔn)確知道最新提交是通過合并進(jìn)來的還是正常提交的。

但是你應(yīng)該還有印象，在合并沖突時，Git會創(chuàng)建一個新的合并提交，其中包含了解決沖突后的更改，并且可以清晰地看到這個合并提交是由哪個分支的哪個提交所觸發(fā)的。這種情況下，就不再是Fast-forward模式了。

這種方式的好處是，在提交歷史中可以清晰地看到合并的細(xì)節(jié)，包括哪個分支的哪些提交被合并了進(jìn)來，以及在合并沖突時是如何解決的。這樣做可以讓我們更容易地理解項目的演變過程，并追蹤到各個提交的來源。

即使在合并完成后刪除了分支，我們?nèi)匀豢梢酝ㄟ^提交歷史來看出實際的合并情況。這種方式不僅提供了更多的歷史信息，還能夠幫助我們更好地理解和管理項目的版本控制歷史。

Git支持我們在合并分支時強制禁用Fast-forward模式，這樣在合并時就會生成一個新的合并提交，即使沒有發(fā)生沖突。這種方式確保了在合并操作后能夠保留分支信息，使得從分支歷史上可以清晰地看出各個分支的合并情況。

通過禁用Fast-forward模式，每次合并都會生成一個新的合并提交，即使在沒有沖突的情況下也會如此。這樣做的好處是，可以在提交歷史中準(zhǔn)確地追蹤到每個分支的合并情況，了解每個提交的來源和影響。

通過這種方式，我們可以更好地管理項目的版本控制歷史，保留各個分支的信息，使得項目的演變過程更加清晰可見。這對于團(tuán)隊協(xié)作和項目維護(hù)都非常有幫助，因為可以更容易地理解和追蹤代碼的變化和來源。

下面我們實戰(zhàn)一下 --no-ff 方式的 git merge。首先，創(chuàng)建新的分支 dev4，并切換至新的分支。接著，修改 ReadMe 文件，并提交一個新的 commit：

?

切回 master 分支，開始合并：

注意，使用 --no-ff 參數(shù)可以禁用Fast-forward模式，在合并分支時創(chuàng)建一個新的提交，即使沒有發(fā)生沖突。而且，結(jié)合 -m 參數(shù)可以在合并時添加一條描述信息，以便記錄這次合并的目的或內(nèi)容。

合并后，查看分支歷史：

可以看到，不使用 Fast forward 模式，merge 后就像這樣：

這樣就成功地使用 --no-ff 方式進(jìn)行了合并，并且創(chuàng)建了一個新的 commit 來保留分支的歷史信息。

分支策略

在實際開發(fā)中，分支管理是非常重要的，它可以幫助我們組織和管理項目的代碼，確保團(tuán)隊成員可以獨立地進(jìn)行工作，并且在需要時可以輕松地將各自的工作集成到主代碼庫中。以下是一些基本的分支管理原則：

1. 穩(wěn)定的主分支（master）： 主分支應(yīng)該是非常穩(wěn)定的，主要用于發(fā)布新版本。在日常開發(fā)中，我們不應(yīng)該直接在主分支上工作，以免影響已經(jīng)發(fā)布或即將發(fā)布的版本的穩(wěn)定性。

2. 開發(fā)活動在開發(fā)分支（dev）上： 實際的開發(fā)活動應(yīng)該在開發(fā)分支上進(jìn)行。開發(fā)分支通常被認(rèn)為是不穩(wěn)定的，因為它是用來集成各種開發(fā)工作的地方。開發(fā)人員可以在這個分支上自由地添加新功能、修復(fù)bug等。

3. 版本發(fā)布通過合并到主分支： 當(dāng)開發(fā)工作完成，一個穩(wěn)定的版本要發(fā)布時，我們可以將開發(fā)分支合并到主分支上。這意味著開發(fā)的新功能和修復(fù)的bug將被集成到主分支中，準(zhǔn)備發(fā)布為新版本。

4. 個人分支（feature branches）： 每個開發(fā)人員通常都有自己的個人分支，用于開發(fā)特定的功能或解決特定的問題。這些個人分支可以從開發(fā)分支（如dev）上創(chuàng)建，并在完成工作后合并回開發(fā)分支。

總的來說，團(tuán)隊成員在開發(fā)過程中應(yīng)該遵循以上原則，將主要的開發(fā)工作集中在開發(fā)分支上，保持主分支的穩(wěn)定性，然后定期將開發(fā)工作合并到主分支上發(fā)布新版本。這樣可以有效地組織團(tuán)隊的工作流程，確保項目的穩(wěn)定性和可維護(hù)性。

所以，團(tuán)隊合作的分?看起來就像這樣：

bug 分支

假設(shè)我們當(dāng)前正在dev4分支上進(jìn)行開發(fā)，但在開發(fā)過程中卻突然發(fā)現(xiàn)了主分支master上存在一個bug需要立即解決。在Git中，我們可以采取一種有效的方式來解決這個問題：針對每個bug，我們可以創(chuàng)建一個新的臨時分支來進(jìn)行修復(fù)。一旦修復(fù)完成，我們將這個臨時分支合并回主分支，然后安全地將其刪除，以保持項目的整潔和可維護(hù)性。

可現(xiàn)在 dev4?的代碼在工作區(qū)中開發(fā)了一半，還無法提交，怎么辦？

我們現(xiàn)在已經(jīng)對dev4中Readme文件進(jìn)行了修改，此時如果我們直接切換回master分支：

?

可以看到工作區(qū)中已經(jīng)進(jìn)行了相應(yīng)的修改。

但是此時我們并不希望在本來穩(wěn)定的master分支上看到我們其他分支修改過的內(nèi)容。

Git提供了git stash命令，用于將當(dāng)前工作區(qū)的修改暫存起來，這樣我們就可以在未來的某個時候恢復(fù)這些被暫存的內(nèi)容。需要注意的是，stash中存儲的是已經(jīng)被我們追蹤管理的文件的修改。換句話說，如果文件尚未被Git追蹤，那么對該文件的修改不會被stash存儲。

??

用 git status 查看?作區(qū)，就是干凈的（除非有沒有被 Git 管理的文件），因此可以放心地創(chuàng)建分 支來修復(fù)bug：

儲藏 dev4 工作區(qū)之后，由于我們要基于master分支修復(fù) bug，所以需要切回 master 分支，再新 建臨時分支來修復(fù) bug：

?

修復(fù)完成后，切換到 master 分支，并完成合并，最后刪除 fix_bug 分支：

至此，bug 的修復(fù)工作已經(jīng)做完了，我們還要繼續(xù)回到 dev4?分支進(jìn)行開發(fā)。

我們切換回 dev4?分支：?

工作區(qū)是干凈的，剛才的工作現(xiàn)場存到哪去了？用?git stash list 命令看看：

當(dāng)我們需要恢復(fù)之前存儲在stash中的工作現(xiàn)場時，可以使用git stash pop命令。這個命令會從stash中恢復(fù)最近一次存儲的工作現(xiàn)場，并將其應(yīng)用到當(dāng)前工作區(qū)中。同時，這個命令也會將這個恢復(fù)的stash從stash列表中刪除，這意味著我們恢復(fù)的同時也將其移出了stash堆棧。?

?

再次查看的時候，我們已經(jīng)發(fā)現(xiàn)已經(jīng)沒有現(xiàn)場可以恢復(fù)了：

另外，恢復(fù)工作現(xiàn)場也可以采用git stash apply命令。不同于git stash pop命令，恢復(fù)后，stash中的內(nèi)容并不會自動刪除，需要我們手動使用git stash drop命令來刪除。這樣就可以保留stash中的內(nèi)容，以備將來再次恢復(fù)使用。

同時，我們可以多次使用stash來保存不同的工作現(xiàn)場。當(dāng)需要恢復(fù)時，我們可以先使用git stash list命令來查看stash堆棧中保存的所有工作現(xiàn)場，然后根據(jù)需要選擇要恢復(fù)的stash。例如，我們可以使用git stash apply stash@{0}命令來恢復(fù)指定的stash。

恢復(fù)完代碼之后我們便可以繼續(xù)完成開發(fā)，開發(fā)完成后便可以進(jìn)行提交。

但我們注意到了，修復(fù) bug 的內(nèi)容，并沒有在 dev4?上顯示。

此時的狀態(tài)圖為：

?

?

Master分支目前最新的提交領(lǐng)先于新建dev4分支時基于的master分支的提交，因此在dev4分支中我們當(dāng)然看不到修復(fù)bug的相關(guān)代碼。

我們的最終目標(biāo)是要讓master分支合并dev4分支的內(nèi)容，通常情況下我們可以切換回master分支直接進(jìn)行合并。然而，這種方式存在一定的風(fēng)險。合并分支時可能會出現(xiàn)沖突，而解決代碼沖突需要我們手動干預(yù)（在master分支上解決）。我們無法保證一次性解決所有的沖突問題，因為在實際項目中，代碼沖突可能涉及數(shù)十行甚至數(shù)百行，解決過程中可能會出現(xiàn)錯誤，導(dǎo)致錯誤的代碼被錯誤地合并到master分支上。

因此，在這種情況下，我們的狀態(tài)是：

?

解決這個問題的一個好的建議就是：最好在自己的分支上先合并master分支，然后再讓master分支去合并dev4分支。這樣做的目的是，如果存在沖突，我們可以在本地分支上解決，并進(jìn)行測試，而不會影響主分支master的穩(wěn)定性。

?

刪除臨時分支

在軟件開發(fā)中，我們經(jīng)常面臨著無窮無盡的新功能需求，這些新功能需要不斷地添加進(jìn)項目中以滿足用戶的需求。

當(dāng)我們要添加一個新功能時，我們肯定不希望因為一些實驗性質(zhì)的代碼而破壞主分支的穩(wěn)定性。因此，每當(dāng)添加一個新功能時，最好的做法是新建一個分支，通常我們將這個分支稱為feature分支。在這個分支上進(jìn)行開發(fā)工作，待功能完成后，再將其合并回主分支，最后可以刪除這個feature分支，以保持項目結(jié)構(gòu)的清晰和整潔。

然而，有時候我們可能會遇到這樣的情況：我們正在某個feature分支上開發(fā)某個功能，但突然間產(chǎn)品經(jīng)理叫停了這個功能的開發(fā)。盡管我們白干了一場，但這個feature分支仍然需要被刪除，因為它已經(jīng)變得無用了。然而，使用傳統(tǒng)的git branch -d命令來刪除分支是不行的。

使用傳統(tǒng)的git branch -d命令來刪除分支時，Git會檢查該分支的commit歷史是否完全合并到其他分支中。如果有任何未合并的更改，Git會阻止分支的刪除，以防止數(shù)據(jù)丟失。這是為了保護(hù)用戶不意外地刪除尚未合并的重要更改，從而防止數(shù)據(jù)丟失或不一致的情況發(fā)生。因此，在上述情況下，由于我們的feature分支雖然被開發(fā)了一半，但在產(chǎn)品經(jīng)理叫停后并沒有被合并到其他分支中，因此使用git branch -d刪除命令會失敗。

在這種情況下，如果確定要刪除未合并的feature分支，可以使用強制刪除分支的命令git branch -D。這個命令會強制刪除分支，即使分支上有未合并的更改，但需要注意的是，使用這個命令會導(dǎo)致未合并的更改永久丟失，因此在使用之前，一定要確保已經(jīng)備份或不再需要這些更改。

文章來源地址http://www.zghlxwxcb.cn/news/detail-844497.html

到了這里，關(guān)于Git學(xué)習(xí)（一）基于本地操作：Git初識、Git安裝（Linux-ubuntu）、Git 基本操作、分支管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！