使用Git的感想 - MrWu94/AndroidNote GitHub Wiki

GitHub，就是看你 做了什么项目 编码风格如何 能不能用 Git 做好版本控制 commit message 写得怎么样 工程管理习惯 等等

怎么正确提交commit message

feat(超文本驱动和资源发现): 增加了 JSON API 方案
fix(请求方法): 更新完资源后应该返回状态码 202
chore(): 增加了补充性质的文件 SUPPLEMENT.md
	
upgrade(Gradle): Upgrade gradle plugin to 2.2.0
feat(Dialog): Add folder to play list
fix(Scan Song): All local songs get deleted when inserting new songs

rebase命令

git rebase --onto git rebase -i 等到基础差不多了，玩玩这两条命令吧。

Git merge 合并让你觉得成就感爆棚，但是看看别人是如何优雅的使用 rebase 衍合分支的，心里总归有点儿羡慕吧。

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

git merge dev

$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was fec145a).

一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 origin/master 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。

请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。

git分支管理策略：http://www.ruanyifeng.com/blog/2012/07/git.html

博客：http://blog.chinaunix.net/uid-27714502-id-3436696.html http://blog.chinaunix.net/uid-27714502-id-3436694.html 学习博客总结的几点：http://ryanhoo.github.io/blog/2014/10/16/why-and-how-to-use-github/