一个三年Android开发的总结-常用的git技巧与误区

常用的git技巧

前文《git的基础知识与协作开发》，对git的基本使用作了流水式的总结。在日常工作中最常用的也往往都是git checkout -b创建新分支，修改之后commit，再然后git push，建立merge请求，等待着代码被review完后merge进入到目标分支。而生活中有着各种不确定来打破固有的模式，你需要寻找些东西来解决它，并回到正确的轨道。这一篇来记录下git的常用技巧与对此的理解，让一个个小插曲，成为乐章的和音。

1. 懒从别名（alias）开始：每次git status或者git checkout输入的字母有点多，可以使用别名来简化操作
   git config –global alias.st status，对应关系git st == git status，即在命令行中输入git st和输入git status的效果是一样的
2. git log：很多命令迅速的查手册是非常好的，但是最常用的命令能有个地方翻翻，一目了然更好。git log可以查询过往的提交历史
   
   • git log –stat [commitid]可以查看提交的commit中修改文件的情况
   • git log commit1…commit3 commit之间的log
   • git log file具体文件的提交历史
     其实，如果直接在Eclipse或AndroidStudio中的话，在右键菜单中都会有git -> show history显示历史的地方，点击具体的文件，可查看完整的文件内容。还有git annotations，可以在文件中查看每行代码最近的修改说明，也等同于在命令行中git blame 文件。如此，对你看到有疑惑的地方，能够方便的查看添加或修改此行代码的原因。
   • git log -L :函数名:文件路径及名，查找某个函数或变量的历史，
   • 提交区间，双点语法：两个分支的提交区间，git log master..test 在test分支而没在master分支的提交;
     多点语法:ref1 ref2 ^ref3 在ref1 ref2 不在ref3的提交
     三点语法：git log master…test –left-right只在master或只在test分支。
3. git patch
   
   • 使用linux通用的patch ，应用git apply patch
     git diff > patch 当前分支上的差异输出到patch文件（自己可以起名字）中
     git diff –cached > patch 与上述的差别是，已经添加到索引中的diff
     git diff branchname –cached > patch，当前分支与branchname的差异输出到patch文件中
   • git特有的 git format-patch，应用git-am
     前者不包含提交现象，后者有，而且会生成相应的commit。我的使用的场景是，有时写了一些测试代码也没提交，其他人也要用，则可以生成一个patch，然后发给对方应用上。当然如果有commit过的话，还可以使用下面的git cherry-pick；
4. git cherry-pick commitid:将commitid应用到当前所在的分支上；
   
   • 此命令在同时有多个版本分支在使用时，非常有用。如当前在开发的是r2.0分支，而在r1.0分支上还有一些bugfix，此时一个在r2.0上修复的问题，也需要立马在r1.0上修复，此时仅需要将修复问题的commitid，cherry-pick到r1.0上即可；
   • 还有场景是当新push的一个分支修复了几个问题，而只需要挑出其中几个时，也需要此命令
5. git remote set-url origin newurl：当你需要迁移仓库时用的到，newurl是新仓库地址
6. git stash：帮助你在切换分支时，保留你做了一半的修改。git 中有一个stash栈，可以通过git stash命令包存未提交的修改（当有新增文件等需要加上-u）
   
   • git stash list可以查看当前保存了哪些（git stash save “说明”，可以为暂存信息起个名，否则看到的都是保存时上次提交信息的说明），每行前都有stash{数字}的索引；
   • git stash apply stash索引，指定应用哪个暂存；还可以通过git stash pop应用的同时删除top暂存
   • git stash drop stash索引,删除指定暂存

git的理解与常见的误区

先简单描述对git的理解，从这些理解中很多误区可能就被解释了。git是一个在内容寻址（content-addressable）文件系统上提供了各种交互命令的工具。
在存储上，可以理解为有四类对象：

• blob对象，存储某个文件内容的具体修改
• tree对象，存储目录的信息
• commit对象，一个指明了顶层tree对象和父提交的对象，包含了作者/提交者信息和提交的说明信息
  再来看分支，它是一个指向某一系列提交（commit）对象之首的指针或引用，再从此提交对象检出所需要的目录信息，目录信息中对每个文件依据blob对象信息检出必要的文件内容
• 标签对象,以一个易记的名字，固定指向一个提交对象的分支引用，同时包含了创建日期，作者及注释等。

有了上述的理解，看看下面的误区
1. 频繁创建分支成本高吗
分支就是些指向提交对象的引用，并不会增加太多额外的开销
2. git merge时，git很智能的自动合并了多个人对同一个文件的修改
merge时，blob对象保存的内容修改位置不一样，当然不会引发问题；如果改动在相同位置，就会出现冲突，有时也许仅是一些空格或换行符
3. cherry-pick过一个commit之后，git branch –contains commitid，发现并没有刚刚的commitid，但是git log中还是能看到修改
cherry-pick是将修改重新应用过来，但是产生了新的提交，导致commitid的变化

推荐看git book，有中文版。欢迎关注微信公众号“编程阳光”，你的关注是我持续的动力。转载请注明出处：http://blog.csdn.net/w7849516230