常用的11个git命令

根据history取出出现频率最高的11个git操作。

1 git rebase

基础：
git rebase用于把一个分支的修改合并到当前分支。
解释：
假设你现在基于远程分支 develop ，创建一个叫 feature 的分支,基点的 commit 为 df 。
在后期的开发过程中，feature 向前前进了三个提交：

f1f2f3

而 develop 也合入了其他同事的三个提交：

d1d2d3

当在feature上合并 develop 后， feature 的log为:

dfd1f1f2d2f3d3dx

dx为develop和feature合并产生的merge_request commit。
但当程序员在merge_request合并之前，在 feature 上 rebase 了 develop 分支，feature的提交将变更为:

f11f22f33f44f55   

这里的f1x和f1并不相同，这是由于git在执行rebase的时候，先将feature中新增的提交暂存起来，然后把develop的提交merge过来，最后再将暂存的提交merge回来。
这时暂存的commit已经被重新生成，时间在develop的提交之后。所以feature这时的log应为：

dfd1d2d3f11f22f33

注意这里并没有merge产生的提交。
另外，如果feature分支已经被push到远端，那么rebase后的feature分支将无法正常推送到远端的feature中，这是因为远程对象的引用关系发生了改变，这时需要进行强制推送。
实际使用中的两种方法:
1 更新母分支，git rebase 目标分支；
2 git pull –rebase remote/目标分支.
冲突处理：
首先处理冲突应当尽量采用手动的方式，仔细确认每一处冲突的处理方式。如对冲突毫无争议，可以采用如下命令快速解决：

$ git checkout --theirs/--ours 

处理外毕后需要add处理过的文件，并将他们合并到最近一次提交（commit的时候加上–amend）。
之所以是amend的形式，是因为rebase是逐commit进行的，冲突产生于当前rebase失败的提交。
注意：
如上面介绍的，执行过rebase后的分支commit发生了改变，必须执行强制推送。当强推后，其实远程的commit也会被改变。
这时如果该分支被团队内多人同时维护，那么其他成员在执行pull的时候，也会提示有冲突（即使代码上并没有冲突）。 推荐的解决方案是其他人重新fetch该分支。
由此可以看出，rebase并不适合多人维护的分支。这就要求我们对于feature和hotfix的实现应该尽量原子化。

2 git cherry-pick

git cherry-pick用于把另一个本地分支的commit修改应用到当前分支。
团队开发中经常会出现一个人需要调用另一个人写的方法，而他的代码还没有合并到主干。
cherry-pick就是为解决这类问题而生的,我们可以将他的分支fetch到我们本地，然后执行 git cherry-pick commit-sha，将这个commit直接拿过来。
cherry-pick支持–edit参数，意思是在拿的过程中再次编辑这个提交;
当有冲突的时候,需要先解决冲突，然后继续提取[–continue]（支持放弃提取[–abort]）。

3 git push

git push命令用于将本地分支的更新，推送到远程主机。
用法：

$ git push <远程主机名> <本地分支名>:<远程分支名>

关于远程主机名的配置，建议查看帮助文档：

$ git remtoe --help

除了向远端推送本地的代码以外，我们还可以通过push来直接删除仓库分支：

$ git push <远程分支名>  :<远程分支>

另外重申：在推送过程中一定要谨慎使用 –force

4 git log

git log是git用来查看提交历史的工具。
之前写过一篇查看log的博客，可以用作参考：
http://blog.csdn.net/lshemail/article/details/51787250

5 git blame

git blame 是查看整个文件的每一行的详细修改信息（SHA串,日期和作者等）的工具。
用法:

$ git blame file_path

代码的问责神器，可以查看每一行代码当前是谁修改的，支持行跳转和搜索等。

6 git show

git show 用来查看指定提交指定文件的修改内容。
用法：

$ git show [sha] file_path    

7 git diff

git diff 用来显示项目的两个不同版本之间的差异，或者显示指定文件的不同之处。
用法：

$ git diff [sha1] [sha2] [file_path]

另外，diff的结果是一个标准的patch结构的文件，我们可以通过apply patch文件来实现代码合并，详见帮助文档：

$ git apply --help

8 git commit

git commit用来提交当前工作空间的修改内容。
这时git中最重要的内容，如何做好提交时能否熟练使用git的关键，我以前摘抄过蒋老师的一篇博客，里面用了很大的篇幅来讲如何提交，可以作为参考：
http://blog.csdn.net/lshemail/article/details/52049457

9 git fetch&git pull

git fetch 是从远程获取最新代码到本地；
git pull 是从远程获取罪行代码并合并到本地。
刚用git的人可能会比较疑惑fetch和pull究竟有什么区别，其实上面已经说得很清楚了，用一个数学表达式来写就是：pull = fetch + merge。
fetch习惯用法：

$ git fetch origin develop:feature/xxx

上面的用法是从远程上获取develop的代码到本地，并重命名成开发分支feature/xxx。
pull的习惯用法：

$ git pull origin feature/xxx$ git pull --rebase origin develop

10 git stash

git stash 用来暂存工作区的修改
当我们正在coding的时候，突然有一个紧急的bug需要处理，工作区内容又没有完成，不适合提交，这时就需要stash登场了，stash会暂时将你本地的修改交给git来保管，当你有时间以后，可以从git的stash的栈中将你的修改重新恢复出来。
常用命令：

$ git stash$ git stash list$ git stash pop [version]  

11 git reflog

git reflog用来查看 所有分支 的 所有操作 记录（包括commit和reset的操作）。
用法：

$ git reset --hard [version]

总结：

上面的是一个命令是我从我的系统中执行history，拿到的是个出现频率最高的命令，可能不是很全，但是我认为应该是日常最常用到的。熟悉最基本的命令，可以提高日常工作效率，也是规范提交的前提。
团队出现过某某以前提交的代码，丢失了，修复过的bug又复现了的问题，我认为这可能跟以前的代码提交和分支管理方式有一定关系，以前每个人都是super admin，每个人都可以向develop上推代码、合代码，当众多的“管理员”先后或者共同维护同一段代码的时候，往往会出现代码冲突，由于每个人都有合并的权限，所以当团队内部合并时沟通不畅时，就有可能会出现丢代码的情况。各个代码管理平台为了解决这类问题，基本都采用了收紧分支合并权限，设置保护分支的形式（code平台的保护分支已经在企业版中上线了，社区版日后也会安排上线）。
我们没有了直接合并代码的权限，那么代码何如只能走线上合并这条路，好在现在的merge request功能已经很完善，既可以进行代码review，又可以完成代码合并。
当主干分支和我们自己的分支同时前进时，合并merge_request后的结果，除了我们的commit不连续以外，好像也并没有什么问题，所以执行rebase、提交原子化等措施似乎也没什么必要，因为我们review代码很多时候往往只关注差异，只要能合并，commit是什么样子并不关心。
但当我们的merge_request有冲突的时候呢？线上不能合并，线下合并又不能推送，这时候rebase就是一条捷径了。当我们执行rebase的时候，git会逐commit的将我们的代码和主干代码进行合并，如果有冲突，那么就停下来将冲突交给我们来解决，由于commit本身只是实现了一个单一的功能，且commit message中包含了这个commit的前因后果，所以往常让我们头疼的冲突也会变得很容易解决了。