1. 狀態
1.1 檔案狀態
2. 分支
2.1 分支常用命令
- git branch xxx：新建分支
- git checkout xxx：切換分支
- git checkout -b xxx：新建分支并切換到該分支（相當于上面兩條命令）
- git branch -d xxx：洗掉分支
- git branch：查看分支串列
- git push origin --delete xxx：洗掉遠程分支
- git fetch：從服務器上拉取資料，當 git fetch 命令從服務器上抓取本地沒有的資料時，它并不會修改作業目錄中的資料，它只會獲取資料然后讓你自己合并，
- git pull：在大多數情況下它的含義是一個 git fetch 緊接著一個 git merge / git rebase 命令
2.2 分支合并
分支合并主要有兩種方式：git merge / git rebase
2.2.1 git merge
git merge 會把兩個分支的最新快照以及二者最近的公共祖先進行三方合并，合并的結果是生成一個新的快照（并提交）
作業中的使用流程
現有主分支 master，開發某種功能的分支 dev，dev 上面的內容已經開發完成了，現在要將 dev 分支上的內容合并到 master
- git checkout master
- git pull（拉取最新代碼，也可以使用 git fetch）
- git merge dev
- ... （解決沖突）
- git push （提交到服務器）
2.2.2 git rebase
現在同樣有主分支 master 與 開發分支 dev，需要將 dev 合并到 master
git rebase 的原理是先找到兩個分支（master 與 dev）的最近公共祖先，然后對比 dev 分支對于該祖先的歷次提交，提取相應的修改并存為臨時檔案，然后將當前分支指向目標分支（master）的最新一次的提交，最后將之前另存為臨時檔案的修改依序應用
作業中的使用流程
- git checkout master（切換到目標分支）
- git pull （拉取最新代碼）（也可以直接執行 git rebase master dev，省去步驟3和步驟4 ）
- git checkout dev （切換到開發分支）
- git rebase master （執行變基操作）
- git checkout master （切換到主分支）
- git merge dev （將 dev 分支上的修改變基到主分支）
- git push （提交到服務器）
變基操作前的分支圖
變基完成后的分支圖
無論是 rebase 還是 merge ，整合的最終結果所指向的快照始終是一樣的，只不過提交的歷史不同罷了，變基是將一系列提交按照原有次序依次應用到另一分支上，而合并是把最終結果合在一起
3. 常用命令
3.1 匯總
git add -i：進入互動式終端模式，可以快速選擇某些檔案被暫存，達成部分提交的目的，另外該模式下還有多種快捷功能，
git commit --amend：修改最近一次提交的提交資訊
git rebase -i：互動式的運行變基，修改多個提交資訊（注意無論是 git commit --amend 還是 git rebase -i 都不能涉及到已經推送到服務器的提交）
git revert：撤銷（還原）某次提交
3.2 git reset 的不同模式
3.2.1 git reset --soft HEAD~
首先要明白 git 的 “三棵樹”，HEAD、Index 以及 Working Directory，HEAD 是指已經 commit 快照，可以將它看做是 該分支上的最后一次提交；Index 是 “暫存區”，是預期的下一次提交；Working Directory 是我們自己的作業目錄，我們在作業目錄中對檔案進行修改，然后添加到暫存區，最后再 commit，HEAD 指向我們最后一次的 commit，
我們運行 git reset --soft HEAD~ 會產生什么效果？下圖是我們現在的分支狀態和 “三棵樹” 的狀態
然后我們運行 git reset --soft HEAD~
可以看到，Index 區和 Working Directory 區的狀態并沒有發生變化，只有 HEAD 指標向前移動了一個節點，git reset --soft HEAD~ 的本質上是撤銷了上一次 git commit 命令，當我們運行 git commit 時，Git 會創建一個新的提交，并移動 HEAD 所指向的分支來使其指向該提交，當將它 reset 回 HEAD~（HEAD 的父結點）時，其實就是把該分支移動回原來的位置，而不會改變 Index 和 Work Directory，現在可以再次運行 git commit 以達到和 git commit --amend 相同的效果，
3.2.2 git reset [--mixed] HEAD~
mixed 是 git reset 操作的默認引數，git reset --mixed HEAD~ 可以重置 Index （暫存區）的檔案與上次的 commit 保持一致，Work Directory 的內容保持不變，
當我們運行 git reset --mixed HEAD~ 時，reset 會用 HEAD 指向的當前快照的內容來更新索引
git reset --mixed HEAD~ 操作共有兩個步驟
-
將 HEAD 指標向前移動一個節點，也就是 git reset --soft HEAD~ 操作
-
重置 Index （暫存區）的檔案與 HEAD 指向的節點保持一致
3.2.3 git reset --hard HEAD~
--hard 是 reset 命令唯一的危險用法，git reset --hard HEAD~ 命令會撤銷最后的提交、git add 和 git commit 命令以及 Work Directory 中所有的作業
git reset --hard HEAD~ 總共有三個步驟
- 將 HEAD 指標向前移一個節點，也就是 git reset --soft HEAD~ 操作
- 重置 Index （暫存區）的檔案與 HEAD 指向的節點保持一致，也就是 git reset --mixed HEAD~ 操作
- 重置 Work Directory 的檔案與 HEAD 和 Index 保持一致
3.2.4 git reset 的其他用法
git reset file.txt（其實是 git reset --mixed HEAD file.txt 的簡寫形式），它的實質是將 file.txt 從 HEAD 復制到 Index ，該命令總共有兩個步驟：
- 移動 HEAD 分支的指向（因為我們給 reset 指定了一個路徑，所以它的作用范圍限定為指定的檔案或檔案集合，而 HEAD 只是一個指標，無法讓它指向兩個提交中各自的一部分，所以該步驟會跳過，HEAD 的指向不變）
- 讓 Index 看起來像 HEAD
因為 git reset file.txt 會產生 Index 與 HEAD 中 file.txt 檔案一模一樣的結果，所以 file.txt 會從 Index （暫存區）被移除，git reset file.txt 與 git add file.txt 所做的事正好相反，所以我們可以使用 git reset file_name 來取消暫存一個檔案，
我們也可以通過指標一個具體的提交來拉取對應的檔案版本，類似于 git reset eb43bf file.txt，這時候再運行 git commit，就會將該版本的 file.txt 提交，
另外，可以使用 git reset --soft HEAD~n 來達到壓縮提交的效果
3.3 git checkout
git checkout [branch]：切換分支，與 git reset --hard [branch] 非常相似，它會更新 “三棵樹”，HEAD、Index、WorkDirectory，不同于 reset --hard，checkout 對于作業目錄是安全的，它會通過檢查來確保不會將已更改的檔案弄丟，并且 reset 會移動 HEAD 分支的走向，而 checkout 只會移動 HEAD 自身來指向另一個分支
git checkout file.txt：它就像 git reset [branch] file 那樣用那次提交中的那個檔案來更新 Index，同時也會覆寫作業目錄中對應的檔案，并不會移動 HEAD
4. git 底層命令
4.1 .git 目錄
- config: 專案特有的配置選項
- info: 包含一個全域性排除檔案，用以放置哪些不希望被記錄在
.gitignore檔案中的忽略模式 - hooks: 包含客戶端或服務端的鉤子腳本
- objects: 存盤所有的資料內容
- refs: 存盤指向資料（分支、遠程倉庫和標簽等）的提交物件的指標
- HEAD: 指向目前被檢出的分支
- index: 保存暫存區資訊
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/509055.html
標籤：其他
上一篇：Github-CLI