Git 小技巧彙總

當commit之後發現程式碼有錯，簡單直接的方法就是進行修改程式碼，然後第二次commit。

這樣git log可以看到兩次commit的資訊

其他思路

如果你commit了之後還沒有推到遠端倉庫，commit資訊還在本地，此時可以根據git log的hashid來重置commit版本資訊。

git reset

git reset –mixed

此為預設方式，不帶任何引數的git reset，即時這種方式，它回退到某個版本，只保留原始碼，回退commit和index資訊

git reset –soft

回退到某個版本，只回退了commit的資訊，不會恢復到index file一級。如果還要提交，直接commit即可

git reset –hard

徹底回退到某個版本，本地的原始碼也會變為上一個版本的內容

修改備註資訊

git commit -amend

忽略檔案

git rm與git rm --cache的區別

當我們需要刪除暫存區或分支上的檔案, 同時工作區也不需要這個檔案了, 可以使用

git rm file_path

git commit -m 'delete somefile'

git push

當我們需要刪除暫存區或分支上的檔案, 但本地又需要使用, 只是不希望這個檔案被版本控制, 可以使用

git rm --cached file_path

git commit -m 'delete remote somefile'

git push

忽略一個已經被跟蹤的目錄（再也不管它了）：

git rm -r --cached dir

echo dir/ >> .gitignore

git add .gitignore

git commit -am 'ignore dir forever'

git alias

第一種方法：

git status

可以設定為

透過配置git本身，

git config --global alias.s status

從此，git s就是git status

第二種方法:

vim ~/.gitconfig

第三種方法;

vi ~/zssrc

配置系統的別名

git stash 可用來暫存當前正在進行的工作，比如想pull 最新程式碼，又不想加新commit，或者另外一種情況，為了fix 一個緊急的bug, 先stash, 使返回到自己上一個commit, 改完bug之後再stash pop, 繼續原來的工作。

基礎命令

$git stash

$do some work

$git stash pop

進階

git stash save "work in progress for foo feature"

當你多次使用’git stash’命令後，你的棧裡將充滿了未提交的程式碼，這時候你會對將哪個版本應用回來有些困惑，

’git stash list’ 命令可以將當前的Git棧資訊列印出來，你只需要將找到對應的版本號，例如使用’git stash apply stash@{1}’就可以將你指定版本號為stash@{1}的工作取出來，當你將所有的棧都應用回來的時候，可以使用’git stash clear’來將棧清空。

git stash # save uncommitted changes

git stash list # list stashed changes in this git

git show stash@{0} # see the last stash

git stash pop # apply last stash and remove it from the list

git stash --help # for more info

rebase 的概念/作用其實很簡單——就是「變基」。具體來說，就是改變一條分支的「基點」，使原分支從指定的地方（commit）重新長出來。並且，由於是一條新分支，你可以隨意修改其中的 commits，也就是——重寫分支歷史。

而 rebase 的主要目的即刪繁就簡。

下面講下關鍵步驟：

git rebase [-i | --interactive] [options] [--exec ] [--onto ] [ []]

git rebase [-i | --interactive] [options] [--exec ] [--onto ] --root []

git rebase --continue | --skip | --abort | --edit-todo

所有 rebase 的操作物件都是 commit。（你可以 rebase 一個分支 git rebase -i branchX，但實際上還是作用於該分支最新的 commit。）

以這個 commit 為「新基點」發起 rebase 後，會列印出一篇 commit 歷史讓你修改。

其中最常用的修改就是把 commit 前的 pick 改為 s (squash, /skwɔʃ/, 意為擠壓)，作用為保留該 commit 作出的修改，但刪去該節點，只給它一個留名的機會。(用專業的話講就是——不保留待合併分支上的歷史資訊，也不提交、不移動HEAD。）多個以 s 為字首的 commit 最終會整合成一個 commit，各個 commit 的描述部分也被整合到一起。

而最終極的修改就是直接刪去 commit(s) ——篡改歷史。這也就意味著，對應的改動也一併灰飛煙滅。（所以為什麼說 rebase 是個危險的操作，就是因為篡改了歷史！想想如果別人基於你國正史 fork 了一條分支，而你日後竟變基了會發生什麼吧！）

改完之後 :x（Vim下的儲存退出命令），Git 就去檢測衝突了，此時類似於合併。

合併將按你留下的 commit(s) 重演歷史，你可以修改每一次 commit 的具體程式碼。而如果你不是為了修改，只是為了簡化樹……我的辦法是隻留下一條 commit，用最新工程完全覆蓋來解決衝突。（不知有沒有更好的方法）

衝突解決完後 git rebase --continue，你就可以正式「書寫」歷史啦——撰寫新的 commit 描述。這時那真是，想怎麼寫就怎麼寫~

這般本地 rebase 完成後，記得 git push -f，-f 用於強制將新歷史推送至遠端倉庫。

至此，rebase 就徹底結束了。

看看你新造的樹吧，是不是特簡潔，特優美？（如果不是……你 rebase 幹嘛……）

當一個系統的專有名詞（黑話）足夠多，就創造了文化。

在貢獻開原始碼時，git rebase可以直接把log同步過來，而不會有 git merge 的log。

打標籤

同大多數 VCS 一樣，Git 也可以對某一時間點上的版本打上標籤。人們在釋出某個軟體版本（比如 v1.0 等等）的時候，經常這麼做。本節我們一起來學習如何列出所有可用的標籤，如何新建標籤，以及各種不同型別標籤之間的差別。

列出已有的標籤

列出現有標籤的命令非常簡單，直接執行 git tag 即可：

git tag

v0.1

v1.3

顯示的標籤按字母順序排列，所以標籤的先後並不表示重要程度的輕重。

我們可以用特定的搜尋模式列出符合條件的標籤。在 Git 自身專案倉庫中，有著超過 240 個標籤，如果你只對 1.4.2 系列的版本感興趣，可以執行下面的命令：

git tag -l 'v1.4.2.*'

v1.4.2.1

v1.4.2.2

v1.4.2.3

v1.4.2.4

新建標籤

Git 使用的標籤有兩種型別：輕量級的（lightweight）和含附註的（annotated）。輕量級標籤就像是個不會變化的分支，實際上它就是個指向特定提交物件的引用。而含附註標籤，實際上是儲存在倉庫中的一個獨立物件，它有自身的校驗和資訊，包含著標籤的名字，電子郵件地址和日期，以及標籤說明，標籤本身也允許使用 GNU Privacy Guard (GPG) 來簽署或驗證。一般我們都建議使用含附註型的標籤，以便保留相關資訊；當然，如果只是臨時性加註標籤，或者不需要旁註額外資訊，用輕量級標籤也沒問題。

含附註的標籤

建立一個含附註型別的標籤非常簡單，用 -a （譯註：取 annotated 的首字母）指定標籤名字即可：

git tag -a v1.4 -m 'my version 1.4'

git tag

v0.1

v1.3

v1.4

而 -m 選項則指定了對應的標籤說明，Git 會將此說明一同儲存在標籤物件中。如果沒有給出該選項，Git 會啟動文字編輯軟體供你輸入標籤說明。

可以使用 git show 命令檢視相應標籤的版本資訊，並連同顯示打標籤時的提交物件。

git show push_v1.2

tag push_v1.2

Tagger: machuang 780@qq.com

Date: Sun Sep 10 12:06:50 2017 +0800

version 1.2 project coding end at 2017-8-23.

This tag create at 2017-9-10

s

commit f1759f45b598611231d9e768

Merge: f8f4 saf9

Author: XScarletAngel 7369@qq.com

Date: Wed Aug 23 18:30:27 2017 +0800

Merge branch 'branch1.2' of git.du.com:admin/admin into branch1.2

'branch1.2' of git.du.com:admin/admin:

Test

我們可以看到在提交物件資訊上面，列出了此標籤的提交者和提交時間，以及相應的標籤說明。

根據commitid打標籤

git tag -a <tag名> <commit對應的hash碼>

tag推送到遠端倉庫

預設情況下，git push並不會把tag標籤傳送到遠端伺服器上，只有透過顯式命令才能分享標籤到遠端倉庫。

1.push單個tag，命令格式為：git push origin [tagname]

例如：

git push origin v1.0 #將本地v1.0的tag推送到遠端伺服器

2.push所有tag，命令格式為：git push [origin] --tags

例如：

git push --tags

或

git push origin --tags

以上命令經檢驗透過，如果不起作用，請在Git控制檯上確認你的賬號是否有許可權推送Tag。