2022/03/31 Git管理的是修改而非資源本身
阿新 • • 發佈：2022-03-31
Git管理的是修改而非資源本身
Git為什麼被稱為最好的分散式專案管理系統
Git跟蹤並管理的是修改，而非檔案。
場景舉例：
建立檔案read.txt--->新增到暫存區git add read.txt--->此時在對read.txt檔案進行修改--->直接commit
此時檢視暫存區狀態：
git status
此時發現第二次修改檔案的內容並沒有被提交到版本庫當中，而是存在暫存區當中
注意：
- 此時的修改發生在工作區而不是暫存區
-
git記錄了本次修改而不是工作區修改後的檔案本身
如何再次提交修改：
再次新增檔案git add--->再次提交git commit
在第一次提交之前再次新增修改的內容：
第一次修改 ---> git add-- -> 第二次修改 ---> git add-- -> git commit
比較工作區和最新版本的區別
git diff HEAD -- 某個檔案完整名稱
總結
- 對於已經在暫存區的檔案進行的修改不會被
commit到master分支上 - 通過
git status檢視的是修改這個動作 - 如果是第一種情況此時的暫存區是乾淨的
撤銷修改
特點：
由於git是對修改進行管理。所以需要注意這裡的撤銷修改有兩種
- 撤銷在工作區的此次修改行為
- 將暫存區的該檔案的修改行為撤銷掉。放回工作區
撤銷修改還由於檔案的是否存在暫存區而導致撤銷的結果不同
當檔案未曾新增到暫存區
撤銷指令：
git checkout -- 檔名稱1 檔名稱2 ...
將檔案回滾到和版本庫一模一樣的狀態
檔案已新增到暫存區
將暫存區的修改拿出來放回工作區：
git reset HEAD 檔名
git reset HEAD <file>
#回退版本的本質是修改head指標指向
git reset --hard HEAD~100
reset引數可以回退版本也可以回退暫存區的修改。這裡需要注意的就是引數的使用
此時在使用git status檢視暫存區的狀態就是空的了
總結
-
git的指令不多。主要是通過引數去控制究竟是進行什麼操作--->git checkout --和git reset HEAD <file> - 時刻注意此次修改位於什麼位置在進行對此次修改的操作
- 此時這些的推送並沒有真正的發生到遠端倉庫的主分支上。如果不小心將不需要的修改移除則可以使用版本回退
git reset --hard HEAD回退到之前版本。只要這個版本還沒有推送到遠端
刪除檔案
對於工作區而言進行的刪除操作
rm <file>
此時檔案只是在工作區刪除了。版本庫還有。並且此時提交會發生衝突檢測到工作區和版本庫不一致
此時可以對檔案進行回滾。因為版本庫當中還有該檔案
git checkout -- <file>
對於工作區和版本庫一起進行的刪除操作
git rm <file>
此時版本庫的檔案和工作區的檔案都刪除了。無法對該檔案進行回滾
總結
-
git的刪除要依據情況來看。刪除工作區、刪除工作區和版本庫 - 工作區刪除可以
checkout，工作區和版本庫一起刪除不可以恢復