基本操作就不說了，這里詳細(xì)介紹其他中高級(jí)操作
1、查看日志
git log
這個(gè)命令對(duì)于提交少的項(xiàng)目比較友好，但是對(duì)于提交很多的項(xiàng)目，會(huì)輸出一大長(zhǎng)串，很不方便，于是有一個(gè)比較簡(jiǎn)便的命令：
git log --pretty=oneline
輸出：
2、撤銷修改
背景
在一個(gè)文件中添加了一點(diǎn)代碼，現(xiàn)在我git add .了但是沒提交，現(xiàn)在我想撤銷我修改的東西
解決方案
兩個(gè)命令：
git reset HEAD src/main/java/com/tinner/demo03/constant/RedisContant.java
git checkout -- src/main/java/com/tinner/demo03/constant/RedisContant.java
效果
3、創(chuàng)建分支
兩個(gè)命令：
git checkout -b dev
git switch -c dev
4、刪除分支
git branch -d <name>
如果要丟棄一個(gè)沒有被合并過的分支，可以通過git branch -D <name>強(qiáng)行刪除。
5、合并代碼
git merge --no-ff -m "注釋。。。。" <分支名>
6、stash
背景
在一個(gè)新的需求開發(fā)過程中，我在dev分支開發(fā)了一些東西，但是并沒有提交我也不想提交，這個(gè)時(shí)候來了一個(gè)bug，我必須將bug改完才能進(jìn)行dev的開發(fā)，那么這個(gè)時(shí)候就需要用到git stash命令
步驟
-
首先，我看看git倉(cāng)庫(kù)中的狀態(tài)
git狀態(tài)
可以看到，在dev分支，我創(chuàng)建了一個(gè)文件，修改了一個(gè)文件。
- 然后，使用
git stash命令，之后再來查看狀態(tài)：
儲(chǔ)藏代碼
此時(shí)工作區(qū)是干凈的。然后我切換到master分支，創(chuàng)建一個(gè)issue分支，解決bug，合并到master，發(fā)版，之后再切換到dev分支，可以看到我的工作區(qū)還是干凈的，那么之前的代碼跑哪去了？ - 使用
git stash list可以查看儲(chǔ)藏的代碼列表
git stash list - 現(xiàn)在我們需要恢復(fù)之前的代碼，有兩個(gè)命令可以參考：
git stash apply
git stash pop
git stash apply命令恢復(fù)后，stash內(nèi)容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復(fù)的同時(shí)把stash內(nèi)容也刪了
- 你可以多次stash，恢復(fù)的時(shí)候，先用
git stash list查看，然后恢復(fù)指定的stash，用命令:
git stash apply stash@{0}
擴(kuò)展
我們知道，master的bug修復(fù)之后，在現(xiàn)在的dev代碼相關(guān)的bug并沒有修復(fù)，所以，這個(gè)bug其實(shí)在當(dāng)前dev分支上也存在。
如何快速修復(fù)？
同樣的bug，要在dev上修復(fù)，我們只需要把修復(fù)issuebug這個(gè)提交所做的修改“復(fù)制”到dev分支。注意：我們只想復(fù)制修復(fù)issuebug這個(gè)提交所做的修改，并不是把整個(gè)master分支merge過來。
為了方便操作，Git專門提供了一個(gè)cherry-pick命令，讓我們能復(fù)制一個(gè)特定的提交到當(dāng)前分支：
git cherry-pick <版本號(hào)>
用git cherry-pick，我們就不需要在dev分支上手動(dòng)再把修bug的過程重復(fù)一遍。
幾個(gè)命令的區(qū)別
merge和rebase的區(qū)別
merge和rebase都是用來合并分支的。
- 采用merge和rebase后，git log的區(qū)別，merge命令不會(huì)保留merge的分支的commit：
- 處理沖突的方式：
（一股腦）使用merge命令合并分支，解決完沖突，執(zhí)行g(shù)it add .和git commit -m 'fix conflict'。這個(gè)時(shí)候會(huì)產(chǎn)生一個(gè)commit。
（交互式）使用rebase命令合并分支，解決完沖突，執(zhí)行g(shù)it add .和git rebase --continue，不會(huì)產(chǎn)生額外的commit。這樣的好處是"干凈"，分支上不會(huì)有無意義的解決分支的commit；壞處：如果合并的分支中存在多個(gè)commit，需要重復(fù)處理多次沖突。
git pull和git pull --rebase
git pull做了兩個(gè)操作分別是獲取和合并。所以加了rebase就是以rebase的方式進(jìn)行合并分支，默認(rèn)為merge。
git merge 和 git merge --no-ff的區(qū)別
git merge –no-ff 可以保存你之前的分支歷史。能夠更好的查看 merge歷史，以及branch 狀態(tài)。
git merge 則不會(huì)顯示 feature，只保留單條分支記錄。
tag相關(guān)
在當(dāng)前分支的最新commit上打tag
git tag v1.0
在f52c633版本的提交上打tag
git tag v0.9 f52c633
查看所有的tag
git tag
注意，標(biāo)簽不是按時(shí)間順序列出，而是按字母排序的
還可以創(chuàng)建帶有說明的標(biāo)簽，用-a指定標(biāo)簽名，-m指定說明文字：
git tag -a v0.1 -m "文字說明" 1094adb
用命令git show <tagname>可以看到說明文字
提交v1.0標(biāo)簽
git push origin v1.0
提交所有的標(biāo)簽
git push origin --tags
從本地刪除tag：
git tag -d v0.9
刪除遠(yuǎn)程tag：
git push origin :refs/tags/v0.9
Git HEAD^與HEAD~的關(guān)系
一張圖：
Git reset后面跟的參數(shù)
比如我在我的本地目錄下面新建了一個(gè)文件c.txt，add到了我的暫存區(qū)（緩沖區(qū)），同時(shí)也commit提交到了本地倉(cāng)庫(kù)
默認(rèn)：git reset = git reset --mixed，這個(gè)命令會(huì)跳轉(zhuǎn)到指定版本、緩存區(qū)的文件還原、但是工作區(qū)（本地目錄）下的文件不會(huì)還原
git reset --hard這個(gè)命令會(huì)跳轉(zhuǎn)到指定版本、緩存區(qū)的文件還原、工作區(qū)（本地目錄）下的文件也會(huì)被還原
git reset --soft這個(gè)命令會(huì)跳轉(zhuǎn)到指定版本、緩存區(qū)的文件不會(huì)被還原、而且工作區(qū)（本地目錄）下的文件也不會(huì)還原
git revert
git revert會(huì)產(chǎn)生一個(gè)commit，撤銷某次操作，此次操作之前和之后的commit和history都會(huì)被保留，并且會(huì)把這次撤銷作為一次最新的提交。
