Git中有很多非常实用且高效的命令，它使得我们可以非常快捷方便的实现代码的版本管理控制。本文总结了Git使用中的8个常用的高效命令，掌握了它们，可以很好的提高我们使用Git的工作效率。

 git commit --amend

git commit --amend命令用于给先前commit的添加新的代码。也就是说当我们使用git commit --amend命令提交代码时，本地仓库中并不会产生一个新的commit，而是将本次提交的代码提交到先前的commit中去，且提交时可以更新先前的commit的提交信息。这样做的好处在于，减少了不必要的commit节点，从而也就降低了工作树的复杂度。毕竟commit节点少一些，工作树更加整洁清晰，我们更容易控制代码的版本。需要注意的是，并非所有的代码的更改都应添加到先前的commit中去，应是情况而定，只有与先前的commit的用途一致的代码才应提交到先前的commit中去。

git commit -am "message"

git commit -am "message"命令用于将工作区中的代码直接提交到本地仓库，而无需手动添加到index区。一般的流程是，当我们修改了代码后，首先应该运行git add <files>命令将代码从工作区放入index区，然后运行git commit命令将其提交到本地仓库中。git commit -am "message"实现了将这两条命令合并在一起的操作，更加快捷高效。简而言之，git commit -am "message" ＝ git add . + git commit -m "message".

 git checkout -b <branch name>

git checkout -b <branch name>命令用于创建一个新的分支并将代码库切换到这个新的分支上去。 为了显示这种功能，一种常见的做法是，首先利用git branch <branch name>创建一个新的branch，然后运行命令git checkout <branch name>将代码库切换到刚才新创建的分支上去。很显然git checkout -b <branch name>命令比它更简单高效。一句话，git checkout -b  ＝ git branch <branch name> + git checkout <branch name>.

 git fetch / git merge

git fetch / git merge这组命令并不见的是真正的高效命令，之所以放在这里是因为这组命令更安全实用。它与git pull这条命令的作用相同，看起来git pull仅仅用一条命令就能搞定的事情，git fetch / git merge需要两条命令才能实现，貌似git pull更高效。其实不然，git pull虽然仅仅用一条命令就可以从远程仓库拉取代码，但它更容出错，也不利于我们拉取代码的时候查看代码的改动部分；而git fetch / git merge这组命令可以使得开发者在利用git fetch拉取代码后，且在merge代码前可以有机会查看代码的改动，进而决定需不需要merge到当前分支中来，因此使用git fetch / git merge可以说是事半功倍。

git cherry-pick <commit ID>

git cherry-pick <commit ID>这条命令非常有意思，它使我们可以在工作树上随意摘取一个或者一组commit到当前的分支。这些commit可以是不同的branch上的。这条命令的好处在于，当我们在一个分支上面进行了代码修改并提交后，有其他的分支也同样需要这些代码的时候，可以通过git cherry-pick <commit ID>命令将想要的commit摘取到当前的分支上，并自动提交到本地仓库。它常常用于这样的一种场景：我们新创建了一个分支用于新的版本1.0的release，同时我们也维护着master分支的代。当我们在master上面发现了bug并将其修复后，我们同样也需要在1.0的分支上将这些修改拿过来，此时git cherry-pick <commit ID>就可以派上用场了，它将这些修改的commit从master分支上摘取过来，并自动提交到当前的分支。

git stash / git stash apply stash@{index}

git stash / git stash apply stash@{index}这组命令可以使我们暂时保存当前的修改，并在之后的某个时间将代码恢复。它的用途非常广泛，而且对于提高我们的工作效率非常有帮助。它常常用于这样一种场景，当我们在一个分支上工作时修改了很多代码，但是任务还没完成，还没有到能够提交代码的程度，这时测试人员发现了一个非常严重的bug，需要我们紧急修复，这时我们怎么做呢？首先要做的就是先运行git stash命令将这些修改暂存，然后我们切换到master命令上去创建一个新的针对这个bug修复的分支，并在这个新的分支上工作。当我们完成修复工作后，我们切换回到之前的分支上，通过命令git stash stash@{index}将之前暂存的改动提取出来，继续我们的工作。

git pull --rebase / git rebase --continue

这组命令主要用于从远程代码库拉取代码到本地，主要针对在一个相同分支上的代码操作（比如master分支）。试想一下，当我们有多个人都在同一个分区上面进行代码操作时，这时候我们拉取代码时会有多少冲突，场面会有多么混乱。如果我们使用git pull或者git fetch从远程拉取代码，那么我们在提交自己新的代码时就会使得整个工作树变得非常凌乱。git pull --rebase / git rebase --continue可以很好的解决这些问题。首先我们将我们改动的代码提交到本地仓库，然后利用git pull --rebase命令将远程仓库的代码拉取到本地，它将其获取的所有的commit放在我们新提交的commit的底部，这步完成后可能会有冲突，等我们将冲突解决完成后，再利用git rebase --continue命令将解决冲突后的代码提交到之前提交的代码中去。通过这两步之后，我们整个的工作树始终会保持在一条直线上，而不会出现代码的merge分支的情况。

git rebase -i master / git rebase --continue

与多人同时工作在一个相同的分支上相比，我们一般真对每个task都会新建一个对应的branch，每个人仅仅工作在自己的分支上，没有人会工作在master上，当工作完成后才会将代码提交到master上去。这样做的好处显而易见，它使得我们无须同时操作相同的分支，尤其是master的分支，从而保证了master分支的整洁与安全。那么这样做的一个关键在于我们在自己的分支上如何与master分支保持一致性。实践中，我们不应在工作切底完成之后，再与master分支同步代码，实践证明，这样会导致大量的冲突，我们应该做的是工作的每天都应该与master同步一次代码，这里仅仅是从master同步新的代码，而不应将自己的代码提交到master分支。git rebase -i master这条命令就是我们最好的工具。它不仅可以让我们当前的分支从master同步最新的代码，而且还可以将我们分支上的多个commit合并成为一个，可以让branch更简洁，毕竟branch上的代码都是为了实现一个功能。如果同步时有冲突，我们解决完冲突后，使用git rebase --continue将代码提交到先前的commit中去。有了这两条命令，我们在不同分支上的工作就会变得简单轻松。