前言

工欲善其事，必先利其器。使用git有一段時間了，一直玩的不深，趁此總結一番，捋捋思路。

正經說事

git config --global alias.xx xxxx
都說不會偷懶的程序員不是好程序員，有些git命令很長，逐字敲總覺得差點意思。萬能的git當然早有準備，提供了別名功能。舉個栗子
設置別名

$ git config --global alias.co checkout
$ git config --global alias.cmt commit
$ git config --global alias.st status

so，對應的，操作就變成了

$ git co branchname
$ git cmt -m "description"
$ git st

有沒有很簡潔

git rebase -i <commitid>^
rebase好好用，手動劃重點
設想你已經commit了，突然發現，有行日志需要加，有段多余代碼忘了刪......如此種種。幾趟下來，大小commit堆了三五個，提交之后，日志看起來未免零散，需要對commit進行合并。
執行git rebase -i "commitID"^（^表示上一次，即包含ID指向的提交）
此時彈出編輯界面如下

整行刪除或將pick改為drop都可將此次commit刪除

對比前后log， 47a5a是不是真的看不到了

drop前

drop后

另，若刪除的是已push到遠程分支的提交，一定要記得git push origin <branchname> -f強制提交，這樣那條惱人的commit就真的消失于無形了。

git rebase <branchname>
神奇的rebase（變基）還有許多功能
最常用如 git rebase <branchname>
指令如其名，先上幾張merge跟rebase操作的對比圖直觀感受一下

操作前

執行git merge后

操作日志

執行git rebase后

操作日志

如果說光看分支結構圖只知道rebase很干凈的把四次提交合并成一條直線的話，reflog就很清晰的告訴我們，rebase操作執行后，branch2分支的兩次提交，真的成功“變基”，重新生成了兩次提交，“入贅”到branch1的提交之后啦。
那么，變基之后，兩分支新的提交都是以此“入贅”點出發生成了對嘛？不急，再試一發對比圖
git rebase branch1后，兩分支分別再次提交

git merge branch1后，兩分支分別再次提交

ok，完美驗證
git tag
除了切換到某個branch，某次commit，我們有可能還需要切回某個成型的版本。比如，“xx你看一下，2.0那個版本用戶投訴有個什么什么問題......”,那么這個時候，只需要'git checkout <tagname>'，就可以一秒回到解放前啦沒毛病
幾個常用命令：
git tag <tagname>打標簽
git tag 查看所有標簽
git tag <tagname> <commitid> 對某次commit打標簽
git show <tagname> 查看標簽信息
git tag -a <tagname> -m "description" 創建帶有說明的標簽
git push origin <tagname> 發布標簽
git push origin --tags 提交本地所有標簽
git checkout <tagname> 切換到標簽
git reset
另一個時光倒流的命令當然要說說 git reset，
常用指令：
git reset HEAD <file> 撤銷對file的add操作
(git checkout -- <file> 撤銷file在工作區的所有修改）
git reset HEAD^ 回退到上一版本（保留本地代碼）
git reset --hard HEAD^ 回退到上一版本（撤銷本地修改）
git reset --hard <commitid> 回退到某次提交（撤銷本地修改）
git gui
執行命令，顯示視圖界面，如下

改動一目了然，再也不用擔心手抖提交了本地測試代碼了