今作此文,尋章摘句,權拋磚引玉,遺笑方家處,敬請見諒
1.搭建環境
- 模擬一個場景
- 打一個 tag 玩(真的是玩)
2.模擬操作
- 現在我們有四個commit 一個tag,並且readme.txt內容如上圖所示,我們知道tag標籤所對應的readme.txt的內容應該爲 “第二次提交” 這個字符串 接下來我們對其進行修改
1. 我們先查看這個標籤對應的內容
2. 切換到master分支,我們通過rebase -i 的方式對其進行修改
3.我們使用edit
(縮寫e) 來對這個commit進行編輯,對於其他的commit我們將其pick
(撿出) wq保存退出
4. 現在我們要開始修改這一次提交了,首先通過 git status
命令查看狀態 git status
一定要多用
5. 我們將 readme.txt 中的 ““第二次提交”” 字符串 修改爲 "fix 第二次提交 通過rebase -i " wq 保存退出 通過 git status
查看狀態
6. 我們將這次修改加入到暫存區並且通過 git status
查看狀態
6. 現在我們已經對這次修改滿意了 我們應該回到 我們當前工作的commit上了 rebase之前的HEAD,在此之前我們需要根據提示 處理一些衝突,首先我們通過 git commit --amend
修改了一下 commit的msg當然也可以不修改
7. 工作樹現在是乾淨的了我們現在可以根據提示進行 git rebase --continue
了
8. 執行了命令之後發現產生衝突了 這裏很好理解 就好比你穿越到了"過去"改變了歷史 那麼"未來"肯定會變啊 (😁)
解決衝突 解決之後記得 git status
查看狀態 與 git rebase --continue
繼續rebase
9. 接下來解決衝突大同小異就不一一列舉了 我們直接跳到最後一步 可以看到歷史已經被改變了 達到了我們我們想要的結果
總結
- 要經常用
git status
命令查看狀態 - 要學會看 git 的強大的提示功能
- 這只是一個示例,在團隊協作中切忌不要亂修改歷史否則後果自負
番外
- 其實一開始打的tag 還是存在的我們還可以找到他