1   git统计报告

2   开发和维护基本过程

在开启了自己的 Github 项目之后，然后就是不断地往里面添加新特性，迭代维护了。

首代产品开发基本的流程如下：

1. 在master分支上开发出第一个可用的项目版本并提交
2. 打上tag并提交测试在ReadMe写好发布版本号及发布特性 tag保证了开发和测试及其它人员描述对象的一致性,开发版和稳定版的tag有不同的命名方式
3. 针对具体的tag的源码进行测试并书写测试报告
4. 测试代码，发现问题，重复（1～3）的步骤，直到最后测试通过后，准备发布前，在ReadMe写好发布版本号及发布特性
5. 给项目打上发布版的tag，正式发布此代码
6. 部署人员将代码部署到生产场景，上线运行

在修复问题的时候，有如下基本流程：

1. 发现bug，或者要增加新特性
2. 在当前分支的当前节点处新建一个dev分支并切换过去
3. 在dev分支上完成功能（同样测试迭代到最后通过测试的“真正”完成）
4. 将dev分支合并到maser分支，并打上发布tag

当然，上述流程只是一种最简单常用的工作流，纯粹是用来抛砖引玉。由于git具有很大的灵活性，用户完全可以根据项目复杂度，团队规模来定义适合自己的工作流。

有兴趣的同学可以搜索 “git 工作流” 或者 "git work flow" ，遵守这些工作流，对规范个人开发习惯或者加强团队协作效率都是极其有帮助的。

3   总结

虽然大牛们总是告诫小白们，不要迷恋工具。但是不可否认，好的工具确实是代表了先进的生产力。

在熟悉了git/github之后，个人可以得到如下改变：

1. 不再为项目版本管理而烦恼
2. 做事永远有后悔药
3. 不用担心电脑硬盘挂掉
4. 可以让项目形成稳定的路线图，整合碎片化的成果
5. 自己的智能成果得到了积累
6. 自己的品牌也会有展现的平台

希望更多的软件版本管理的初学者们能够尽快的养成良好的版本管理系统和高效的版本管理手段，别的不说，至少有一点非常重要的作用就是：

能够保证让软件项目组所有的人描述一个项目对象时，精确的确定是同一对象，这样可以少去很多麻烦，少去很多扯皮拉筋的不必要的冲突。

这应该是在群体性软件活动里面，除了协作之外个人认为最大的作用了—— 一个公正的物证平台。