规范化的软件项目演进管理--从 Github 使用说起
规范化的软件项目演进管理
从 Github 使用说起
1 前言
首先，本文的层次定位是：很基本很基础的 Github 工具的入门级应用，写给入门级的用户看的。
基本上工作过几年的人，下面描述的这些技能和思想，都应该被打磨成了一种习惯，或者说是标配的属性了吧，已经不齿于列为 技能 了。但是因为笔者也菜鸟过，在学习这些技能，接受这些思想和培养这些习惯时走过不少弯路，同时也浪费了不少时间，所以想把这些经验和教训写下来，给后来人学习时提供一点参考意见吧。
关于为什么要学会用 Github ，先用最朴素的比方来开头的引子吧。
就拿年轻人置业买房来说，先不说房子的市场属性和社会属性的种种不好，单说它的好处：“房子（House）实际是一个家（Home）的实际物理载体，有了它之后，家庭或者个人的生活经历能够得到持续的积累和传承，家里的用品和设备也能得到比较好的积累，而不是像 租房 打游戏战的时候，每迁移一个地方就面临着一大堆东西的舍弃，更不用说自己会花些心思在家的小细节装饰和整体风格上做功课了”
Github 就是这样，相当于给了你的智力成果一个房子，一个家，让你在这上面不断形成积累，而且会强化你这些碎片化的积累，最后形成气候，同时因为是“家”，主人也会在情感上更加珍惜，更加的专注的投入，对细节进行打磨，这样最后才可能做出精品。
2 准备工作
2.1 预备知识
- Git版本管理的基本理念
-
- 免费
- 分布式
- 版本控制系统
-
Git的客户端管理工具 [1]
关于Git版本管理的基本理念，可以直接看官方文档 [2] ,各国语言都有，自然也少不了中文 [3] ，但是建议英文好的同学，直接阅读英文原版，这样有助于理解命令。如果喜欢看出处的纸质教程的，国内也相应的出版物：《Git权威指南》 [4] 可以参考。
由于Git的理论和操作是属于工具型的，最好的办法就是多在项目中磨炼，熟练即可，其实常用的功能了并不多，上手也不难。
本文中使用的客户端管理工具是：Linux平台下的git工具。
在Linux下安装git客户端很容易，只需要在机器联网状态下，使用如下命令即可：
sudo apt-get install git
如果在Linux Desktop里面需要可视化界面，则安装：
sudo apt-get install gitk
| [1] | 《Git客户端及图形工具》 |
| [2] | 《GitBook-Pro》 |
| [3] | 《GitBook-Pro-中文》 |
| [4] | 《Git权威指南》 |
2.2 预备平台
在掌握了基本的git的版本管理理念之后，就需要实地操作了。所幸的是，对于普通的个人或者小团队开发者，已经有成熟稳定的git公共服务提供商。普通开发者，不用去搭建git的服务器及服务管理系统，就可以轻松便捷的享受到git的远端备份和协作服务了。
注意
如果是纯粹的个人开发者，而且也没有云端备份和多人协作的需求人，直接在本地机器就安装git客户端就可以使用离线和git版本管理系统了。当然如果想自己搭建私有的git远端仓库服务器，由于git开源的特性，同样也很容易获得丰富的文档和技术支持。
因为项目版本管理及项目交流协作的重要性，国内外已经有很多相当成熟的 git 公共服务了。
国际上有：
国内有：
- 开源中国 git@osc
关于以上几类服务的选择，可以参考如下规则：
- 如果想国际化，又有开放精神的，请选择Github，仅对开源项目免费支持
- 如果想国际化，想建立私有项目的，请选择Bitbucket，个人团队可以免费建立私人项目
- 如果想获得更多的私人项目的权限，请选择 git@osc，支持1000个免费项目，不限制私有或公有。
由于在 IT 界， Github 基本上成为了程序员的精神圣地，成为了git的代码名，所以对于初入此门的用户来说，最好也要在 “行业圣地” 安营扎寨。
只需要完成如下两个步骤，就可以使用 Github 提供的服务了：
- 注册一个 Github 的账号
- 创建一个 Github 项目主页
而更高级的全球化 "码农" 社交，还至少需要如下动作：
- Watch一个大牛的项目，时刻关注动态，紧跟步伐
- Fork一个项目，自己修改，成为社区贡献者
下面将以 Github 对具体对象，来讲解如何使用git工具来
3 项目内容
- 可正常运行源代码
- 项目简介文档-ReadMe
本文将以一个 Github 开源项目为例子进行简单讲解。
本文 GitHub 项目示例
3.1 源码
这个的重要性就自然不用说了。既然是开启了代码项目，项目就一定会有它的作用。
一般是如下一个或者几个作用：
- 个人兴趣练手
- 存储和记录某些信息，比如文档
- 为某个需求提供生产力
- 提供某种功能的开源解决方案，服务大众
- 其它。。。
IT界流传过这样一句极端的话： 不产生生产力的代码实际上和垃圾没有什么区别 。 这句话有些极端，毕竟有时候出于学习和兴趣的代码也其实也有它的存在意义的。总之，话不多说，这些话不管极端还是中肯，其实主要是表达一个意思：你要让做的事情有它的价值，你才会有动力长久维护下去，而一般情况下，源码就是最基本的IT项目的价值体现载体。
示例项目中的价值体现就在于java的源码项目，解决的问题就是：提供一种验证服务的部署SDK。而且这个项目一直在随着业务升级在不断的迭代更新，已经部署到N多服务器上，持续的产生着生产力，所以有人Wathc,Star这些都不奇怪了。
3.2 项目简介
项目简介，就是项目源码的 “配套” 设施。是一种最快速让别人了解你项目的向导说明。在 Github 中的体现就是ReadMe。
这里面的项目简介，还不是像wiki那样的重试文档系统，而是在项目根目录下的 ReadMe 文本文档。一般的Git的公共服务提供商，例如：Github ， Bitbucket 都会默认将项目根目录下的 ReadMe 文件进行渲染，以主页文档的方式呈现出来。
项目简介支持两种渲染格式：
- Markdown
-
- 优点
-
语法简单，上手容易，适合写小型博客文摘
- 缺点
-
支持的语言特性有限，不太适合开发大型文档系统
- RestructuredText
-
- 优点
-
语法特性丰富，适合小，中，大型文档的系统开发
- 缺点
-
实现复杂高级的功能时上手的门槛也比较高
两种写文档的方式的具体细节可以到网上查阅相应的语法即可，在此不再赘述。总之，熟练使用这两种语言中的一种，可以使得写文档者以后就更多的关注于文档的内容的产生，而不是格式的调整了。
个人比较偏爱 restructuredText 来写ReadMe，主要原因如下：
- 天然支持生成目录及文章锚点
- 支持文章内交叉引用
- 有比较友好的表格语法
- 很多很多的其它很强的语法特性
- 自己在开发大型文档的时候都使用rst，所以就不用和markdown混用了
一个比较典型的ReadMe的内容应包括但不限于：
- 目录
- 项目介绍
- 安装方法
- 使用Demo
- 发布路线图
具体可以参考示例项目的 ReadMe 的写法。
4 常用功能
一个常见 Github 项目，常用的功能图如下：
即：
- commits 提交记录
- branches 分支
- release 发布版本
下面将针对每一块进行详细介绍。
4.1 commits
用户在本地的工作空间里面为项目添加新功能或者修改bug，不断的提交，更新项目的版本，这样促使项目不断的向前推进迭代。这些提交过程(commits)日积月累，就由git形成了稳定的提交线路图。
原则上，用户应该尽量勤快提交，因为这样可以小步快速迭代，而且即使出了问题也可以在回滚的版本精确度也会更高：git可以将项目版本恢复到任何的纳入版本管理的提交节点处。
4.2 branches
分支是git最重要的特性，这是项目要进行比较大的修改，而且要保证原分支特性能够得到妥善管理时的一个重要功能。使用分支功能，可以很方便的看到产品的各种重要衍生阶段和归并阶段，同时也极大的方便了开发者在这几个分支之间进行切换。
针对此特性，还诞生了不少工作流，比较典型的分支工作流如下图：
4.3 releases
在git中除了 分支branch 的概念外，还有 标签tag 的概念。
通过tag的相应命令，为某个里程碑的可发布版本打上标签，推送到 Github 上之后的体现形式就是在 relases 选项卡里面提供了tag的各种线路图，直接打包成压缩包文件供用户统一下载。
当然此处也可以针对每个发布的节点标签写上发布日志，但是一般不建议这样，因为这样这些信息就存储在 Github 信息系统里面了，而不是存储在git项目里面了。一般建议将这些信息写在ReadMe里面，这样可以维持项目的完整性，同时也没有丢失掉项目线路图的具体迭代描述。
5 开发和维护基本过程
在开启了自己的 Github 项目之后，然后就是不断地往里面添加新特性，迭代维护了。
首代产品开发基本的流程如下：
- 在master分支上开发出第一个可用的项目版本并提交
- 打上tag并提交测试在ReadMe写好发布版本号及发布特性 tag保证了开发和测试及其它人员描述对象的一致性,开发版和稳定版的tag有不同的命名方式
- 针对具体的tag的源码进行测试并书写测试报告
- 测试代码，发现问题，重复（1～3）的步骤，直到最后测试通过后，准备发布前，在ReadMe写好发布版本号及发布特性
- 给项目打上发布版的tag，正式发布此代码
- 部署人员将代码部署到生产场景，上线运行
在修复问题的时候，有如下基本流程：
- 发现bug，或者要增加新特性
- 在当前分支的当前节点处新建一个dev分支并切换过去
- 在dev分支上完成功能（同样测试迭代到最后通过测试的“真正”完成）
- 将dev分支合并到maser分支，并打上发布tag
当然，上述流程只是一种最简单常用的工作流，纯粹是用来抛砖引玉。由于git具有很大的灵活性，用户完全可以根据项目复杂度，团队规模来定义适合自己的工作流。
有兴趣的同学可以搜索 “git 工作流” 或者 "git work flow" ，遵守这些工作流，对规范个人开发习惯或者加强团队协作效率都是极其有帮助的。
6 总结
虽然大牛们总是告诫小白们，不要迷恋工具。但是不可否认，好的工具确实是代表了先进的生产力。
在熟悉了git/github之后，个人可以得到如下改变：
- 不再为项目版本管理而烦恼
- 做事永远有后悔药
- 不用担心电脑硬盘挂掉
- 可以让项目形成稳定的路线图，整合碎片化的成果
- 自己的智能成果得到了积累
- 自己的品牌也会有展现的平台
希望更多的软件版本管理的初学者们能够尽快的养成良好的版本管理系统和高效的版本管理手段，别的不说，至少有一点非常重要的作用就是：
能够保证让软件项目组所有的人描述一个项目对象时，精确的确定是同一对象，这样可以少去很多麻烦，少去很多扯皮拉筋的不必要的冲突。
这应该是在群体性软件活动里面，除了协作之外个人认为最大的作用了—— 一个公正的物证平台。
| 作者: | Harmo哈莫 |
|---|---|
| 作者介绍: | https://zhengwh.github.io |
| 技术博客: | http://www.cnblogs.com/beer |
| Email: | dreamzsm@gmail.com |
| QQ: | 1295351490 |
| 时间: | 2015-10 |
| 版权声明: | 欢迎以学习交流为目的读者随意转载，但是请 【注明出处】 |
| 支持本文: | 如果文章对您有启发，可以点击博客右下角的按钮进行 【推荐】 |
