之前寫的 Git基本操作命令
眾所周知遏弱， Git目前已經(jīng)是分布式版本控制領(lǐng)域的翹楚，圍繞著Git形成了了一個完整的生態(tài)圈塞弊，學(xué)習(xí)Git漱逸，首先當(dāng)然水學(xué)習(xí)Git的基本工作流，相比于SVN等傳統(tǒng)的版本控制系統(tǒng)來說游沿，Git是專為分布式版本控制而生的強大工具饰抒，使用Git時常用的命令:pull,commit,push 等 貌似很簡單。不過诀黍，有時你會遇到合并沖突的情況袋坑，Git這時會將沖突標(biāo)記出來，需要你手工來解決眯勾。有時枣宫，你會不小心將代碼提交到錯誤的分支上，并且又推送到了遠程 倉庫吃环。還有些時候也颤，你需要切換到不同的分支，但Git卻不讓你這么做郁轻，因為還有未保存的修改翅娶。如果需要通過另一個分支的提交來為代碼打補丁該怎么做呢？本 文就將介紹12個Git高級命令好唯，合理使用這些命令可以大大提升應(yīng)用Git的效率竭沫。
一 rebase拉上游修改
使用rebase而非merge來拉取上游修改。分支合并會被記錄為一次合并提交骑篙，這種做法是很有意義的蜕提。比如說，可以通過這種方式來標(biāo)識一個新特性被合并到了發(fā)布分支中靶端。不過谎势，當(dāng)多個團隊成員工 作在一個項目中并使用常規(guī)的git pull來同步分支時，提交時間線就會被不必要的合并提交所污染躲查。更好的做法則是使用git rebase將一個feature分支變基到master分支：
git checkout feature
git rebase master
這么做會將整個feature分支移動到master分支的起點它浅，它會合并master分支上所有新的提交译柏。不過镣煮，相比于使用合并提交來說，變基會 通過在原來的分支中為每次提交創(chuàng)建全新提交來重寫項目歷史鄙麦。變基的主要好處在于你會得到一個更加整潔的項目歷史典唇。此外镊折，這里還有關(guān)于變基的陷阱的一些討 論
二 在執(zhí)行git rebase后并解決合并沖突
- 在執(zhí)行g(shù)it rebase后解決合并沖突。正如能力越大責(zé)任就越大一樣介衔。在執(zhí)行g(shù)it rebase時恨胚，你可能會遇到合并沖突的情況。合并沖突表示兩個提交修改了同一個文件的同一行炎咖，Git不知道該應(yīng)用哪一個修改赃泡。這會導(dǎo)致如下所示的錯誤消息：
- Git會為你提供3個選擇來修復(fù)導(dǎo)致沖突的提交
- 1 可以運行g(shù)it rebase –abort來完全取消變基。這么做會取消變基修改乘盼，并將分支置回到執(zhí)行g(shù)it rebase之前的狀態(tài)升熊。
- 2 可以運行g(shù)it rebase –skip來完全忽略該提交。這樣绸栅，有問題的提交所引入的變化就不會被添加到歷史中级野。
- 3 可以使用與合并沖突相同的標(biāo)準步驟來解決沖突
三 臨時性保存修改
- 在工作進行中時，有些東西常常會處于凌亂的狀態(tài)粹胯。如果這時需要切換到不同的分支該怎么辦呢蓖柔？Git是不允許你這么做的，因為還有尚未保存的修改风纠。坦 率地說况鸣，你并不想將半成品提交上去，后面再來修改议忽。這個問題的解決之道就是使用git stash命令懒闷。Stash會接收工作目錄的當(dāng)前狀態(tài)（比如說，修改了的追蹤文件與暫存區(qū)的修改等）栈幸，并將其保存到未完成的修改棧中愤估，這樣后面隨時可以再 來修改∷僦罚可以通過如下命令來暫存你的工作：
$ git stash Saved working directory and index state WIP on feature: 3fc175f fix race condition HEAD is now at 3fc175f fix race condition
好了玩焰，現(xiàn)在工作目錄就是干凈的了
git status : On branch feature nothing to commit, working directory clean
這時就可以安全地切換分支做別的事情了。不過不必擔(dān)心芍锚，暫存的提交依舊還在
git stash list stash@{0}: WIP on feature: 3fc175f fix race condition
稍后昔园，在回到feature分支后，你就可以取回所有暫存的變更了：
$ git stash pop On branch feature Changes not staged for commit: (use "git add ..." to update what will be committed) modified: index.html Dropped refs/stash@{0} (ac2321cc3a33ba712b8e50c99a99d3c20da9d6b8)
關(guān)于暫存 還有一些其它選項可用 如下所示：
$ git stash save "describe it" # give the stash a name
$ git stash clear # delete a stashed commit
$ git stash save --keep-index # stash only unstaged files
四 克隆一個特定的遠程分支
如果想要從遠程倉庫中克隆一個特定的分支該怎么做呢并炮？通常你會使用git clone默刚，不過這么做會將所有其他分支都一并克隆下來。一個便捷的方式是使用git remote add：
$ git init
$ git remote add -t -f origin
$ git checkout
五 將cherry-pick遠程提交合并到自己的分支中
更有甚者逃魄，如果只想將遠程倉庫的一個特定提交合并到自己的分支中該怎么做呢荤西？可以使用git cherry-pick 來選擇給定SHA值的提交，然后將其合并到當(dāng)前分支中：
$ git cherry-pick
六 應(yīng)用來自不相關(guān)的本地倉庫的補丁
如果需要將另一個不相關(guān)的本地倉庫的提交補丁應(yīng)用到當(dāng)前倉庫該怎么做呢？答案就是下面這條命令：
$ git --git-dir=/.git format-patch -k -1 --stdout | git am -3 -k
七 忽略追蹤文件中的變更
如果你和你的同事操縱的是相同分支邪锌，那么很有可能需要頻繁執(zhí)行g(shù)it merge或是git rebase勉躺。不過，這么做可能會重置一些與環(huán)境相關(guān)的配置文件觅丰，這樣在每次合并后都需要修改饵溅。與之相反，你可以通過如下命令永久性地告訴Git不要管某個本地文件：
$ git update-index --assume-unchanged
八 每隔x秒運行一次git pull
通常妇萄，合并沖突出現(xiàn)的原因在于你正在工作的本地倉庫不再反映遠程倉庫的當(dāng)前狀態(tài)蜕企。這正是我們?yōu)槭裁疵刻煸绯恳紫葓?zhí)行一次git pull的緣故。此外冠句，你還可以在后臺通過腳本（或是使用GNU Screen）每隔X秒調(diào)用一次git pull：
$ screen $ for((i=1;i<=10000;i+=1)); do sleep X && git pull; done
九 將子目錄分隔為新的倉庫
有時糖赔，你可能需要將Git倉庫中某個特定的目錄轉(zhuǎn)換為一個全新的倉庫。這可以通過git filter-branch來實現(xiàn)：
$ git filter-branch --prune-empty --subdirectory-filter master
# Filter the master branch to your directory and remove empty commits Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89) Ref 'refs/heads/master' was rewritten
現(xiàn)在 倉庫會包含指定子目錄中的所有文件轩端。雖然之前的所有文件都會被刪除放典，但是他們依舊存在于Git歷史中,現(xiàn)在可以將新的本地倉庫推送到遠程了
十清理
有時 Git提示 untracked working tree files 會overwritten by checkout 造成這種情況的原因有很多。不過通常來說基茵，我們可以使用如下命令來保持工作樹的整潔奋构，從而防止這種情況的發(fā)生：
$ git clean -f # remove untracked files
$ git clean -fd # remove untracked files/directories
$ git clean -nfd # list all files/directories that would be removed
十一 將項目文件打成tar包，并且排除.git目錄
有時拱层，你需要將項目副本提供給無法訪問GitHub倉庫的外部成員弥臼。最簡單的方式就是使用tar或zip來打包所有的項目文件。不過根灯，如果不小心径缅，隱藏的.git目錄就會包含到tar文件中，這會導(dǎo)致文件體積變大烙肺；同時纳猪，如果里面的文件與接收者自己的Git倉庫弄混了，那就更加令人頭疼了桃笙。輕松的做法則是自動從tar文件中排除掉.git目錄：
$ tar cJf .tar.xz / --exclude-vcs
十二 查找修改者
最后氏堤，如果出現(xiàn)混亂的情況，你一定想要找出是誰造成的搏明。如果生產(chǎn)服務(wù)器宕機鼠锈，那么找到罪魁禍首是比較容易的事情：只需執(zhí)行g(shù)it blame。該命令會顯示出文件中每一行的作者星著，提交hash則會找出該行的上一次修改购笆，還能看到提交的時間戳：
$ git blame
最全的Git詳解 https://git-scm.com/book/zh/v2
