Git中有很多非常實(shí)用且高效的命令，它使得我們可以非常快捷方便的實(shí)現(xiàn)代碼的版本管理控制。本文總結(jié)了Git使用中的8個(gè)常用的高效命令，掌握了它們，可以很好的提高我們使用Git的工作效率。
?git commit --amend
git commit --amend命令用于給先前commit的添加新的代碼。也就是說當(dāng)我們使用git commit --amend命令提交代碼時(shí)，本地倉庫中并不會(huì)產(chǎn)生一個(gè)新的commit，而是將本次提交的代碼提交到先前的commit中去，且提交時(shí)可以更新先前的commit的提交信息。這樣做的好處在于，減少了不必要的commit節(jié)點(diǎn)，從而也就降低了工作樹的復(fù)雜度。畢竟commit節(jié)點(diǎn)少一些，工作樹更加整潔清晰，我們更容易控制代碼的版本。需要注意的是，并非所有的代碼的更改都應(yīng)添加到先前的commit中去，應(yīng)是情況而定，只有與先前的commit的用途一致的代碼才應(yīng)提交到先前的commit中去。
git commit -am "message"
git commit -am "message"命令用于將工作區(qū)中的代碼直接提交到本地倉庫，而無需手動(dòng)添加到index區(qū)。一般的流程是，當(dāng)我們修改了代碼后，首先應(yīng)該運(yùn)行g(shù)it add <files>命令將代碼從工作區(qū)放入index區(qū)，然后運(yùn)行g(shù)it commit命令將其提交到本地倉庫中。git commit -am "message"實(shí)現(xiàn)了將這兩條命令合并在一起的操作，更加快捷高效。簡而言之，git commit -am "message" ＝ git add . + git commit -m "message".
?git checkout -b <branch name>
git checkout -b <branch name>命令用于創(chuàng)建一個(gè)新的分支并將代碼庫切換到這個(gè)新的分支上去。 為了顯示這種功能，一種常見的做法是，首先利用git branch <branch name>創(chuàng)建一個(gè)新的branch，然后運(yùn)行命令git checkout <branch name>將代碼庫切換到剛才新創(chuàng)建的分支上去。很顯然git checkout -b <branch name>命令比它更簡單高效。一句話，git checkout -b ?＝ git branch <branch name> + git checkout <branch name>.
?git fetch / git merge
git fetch / git merge這組命令并不見的是真正的高效命令，之所以放在這里是因?yàn)檫@組命令更安全實(shí)用。它與git pull這條命令的作用相同，看起來git pull僅僅用一條命令就能搞定的事情，git fetch / git merge需要兩條命令才能實(shí)現(xiàn)，貌似git pull更高效。其實(shí)不然，git pull雖然僅僅用一條命令就可以從遠(yuǎn)程倉庫拉取代碼，但它更容出錯(cuò)，也不利于我們拉取代碼的時(shí)候查看代碼的改動(dòng)部分；而git fetch / git merge這組命令可以使得開發(fā)者在利用git fetch拉取代碼后，且在merge代碼前可以有機(jī)會(huì)查看代碼的改動(dòng)，進(jìn)而決定需不需要merge到當(dāng)前分支中來，因此使用git fetch / git merge可以說是事半功倍。
git cherry-pick <commit ID>
git cherry-pick <commit ID>這條命令非常有意思，它使我們可以在工作樹上隨意摘取一個(gè)或者一組commit到當(dāng)前的分支。這些commit可以是不同的branch上的。這條命令的好處在于，當(dāng)我們?cè)谝粋€(gè)分支上面進(jìn)行了代碼修改并提交后，有其他的分支也同樣需要這些代碼的時(shí)候，可以通過git cherry-pick <commit ID>命令將想要的commit摘取到當(dāng)前的分支上，并自動(dòng)提交到本地倉庫。它常常用于這樣的一種場景：我們新創(chuàng)建了一個(gè)分支用于新的版本1.0的release，同時(shí)我們也維護(hù)著master分支的代。當(dāng)我們?cè)趍aster上面發(fā)現(xiàn)了bug并將其修復(fù)后，我們同樣也需要在1.0的分支上將這些修改拿過來，此時(shí)git cherry-pick <commit ID>就可以派上用場了，它將這些修改的commit從master分支上摘取過來，并自動(dòng)提交到當(dāng)前的分支。
git stash / git stash apply stash@{index}
git stash / git stash apply stash@{index}這組命令可以使我們暫時(shí)保存當(dāng)前的修改，并在之后的某個(gè)時(shí)間將代碼恢復(fù)。它的用途非常廣泛，而且對(duì)于提高我們的工作效率非常有幫助。它常常用于這樣一種場景，當(dāng)我們?cè)谝粋€(gè)分支上工作時(shí)修改了很多代碼，但是任務(wù)還沒完成，還沒有到能夠提交代碼的程度，這時(shí)測試人員發(fā)現(xiàn)了一個(gè)非常嚴(yán)重的bug，需要我們緊急修復(fù)，這時(shí)我們?cè)趺醋瞿兀渴紫纫龅木褪窍冗\(yùn)行g(shù)it stash命令將這些修改暫存，然后我們切換到master命令上去創(chuàng)建一個(gè)新的針對(duì)這個(gè)bug修復(fù)的分支，并在這個(gè)新的分支上工作。當(dāng)我們完成修復(fù)工作后，我們切換回到之前的分支上，通過命令git stash stash@{index}將之前暫存的改動(dòng)提取出來，繼續(xù)我們的工作。
git pull --rebase / git rebase --continue
這組命令主要用于從遠(yuǎn)程代碼庫拉取代碼到本地，主要針對(duì)在一個(gè)相同分支上的代碼操作（比如master分支）。試想一下，當(dāng)我們有多個(gè)人都在同一個(gè)分區(qū)上面進(jìn)行代碼操作時(shí)，這時(shí)候我們拉取代碼時(shí)會(huì)有多少?zèng)_突，場面會(huì)有多么混亂。如果我們使用git pull或者git fetch從遠(yuǎn)程拉取代碼，那么我們?cè)谔峤蛔约盒碌拇a時(shí)就會(huì)使得整個(gè)工作樹變得非常凌亂。git pull --rebase / git rebase --continue可以很好的解決這些問題。首先我們將我們改動(dòng)的代碼提交到本地倉庫，然后利用git pull --rebase命令將遠(yuǎn)程倉庫的代碼拉取到本地，它將其獲取的所有的commit放在我們新提交的commit的底部，這步完成后可能會(huì)有沖突，等我們將沖突解決完成后，再利用git rebase --continue命令將解決沖突后的代碼提交到之前提交的代碼中去。通過這兩步之后，我們整個(gè)的工作樹始終會(huì)保持在一條直線上，而不會(huì)出現(xiàn)代碼的merge分支的情況。
git rebase -i master / git rebase --continue
與多人同時(shí)工作在一個(gè)相同的分支上相比，我們一般真對(duì)每個(gè)task都會(huì)新建一個(gè)對(duì)應(yīng)的branch，每個(gè)人僅僅工作在自己的分支上，沒有人會(huì)工作在master上，當(dāng)工作完成后才會(huì)將代碼提交到master上去。這樣做的好處顯而易見，它使得我們無須同時(shí)操作相同的分支，尤其是master的分支，從而保證了master分支的整潔與安全。那么這樣做的一個(gè)關(guān)鍵在于我們?cè)谧约旱姆种先绾闻cmaster分支保持一致性。實(shí)踐中，我們不應(yīng)在工作切底完成之后，再與master分支同步代碼，實(shí)踐證明，這樣會(huì)導(dǎo)致大量的沖突，我們應(yīng)該做的是工作的每天都應(yīng)該與master同步一次代碼，這里僅僅是從master同步新的代碼，而不應(yīng)將自己的代碼提交到master分支。git rebase -i master這條命令就是我們最好的工具。它不僅可以讓我們當(dāng)前的分支從master同步最新的代碼，而且還可以將我們分支上的多個(gè)commit合并成為一個(gè)，可以讓branch更簡潔，畢竟branch上的代碼都是為了實(shí)現(xiàn)一個(gè)功能。如果同步時(shí)有沖突，我們解決完沖突后，使用git rebase --continue將代碼提交到先前的commit中去。有了這兩條命令，我們?cè)诓煌种系墓ぷ骶蜁?huì)變得簡單輕松。
