规范化的软件项目演进管理--从 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 公共服务了。

国际上有：

• GitHub
• Bitbucket

国内有：

• 开源中国 git@osc

关于以上几类服务的选择，能够参考以下规则：

• 若是想国际化，又有开放精神的，请选择Github，仅对开源项目免费支持
• 若是想国际化，想创建私有项目的，请选择Bitbucket，我的团队能够免费创建私人项目
• 若是想得到更多的私人项目的权限，请选择 git@osc，支持1000个免费项目，不限制私有或公有。

因为在 IT 界， Github 基本上成为了程序员的精神圣地，成为了git的代码名，因此对于初入此门的用户来讲，最好也要在 “行业圣地” 安营扎寨。

只须要完成以下两个步骤，就可使用 Github 提供的服务了：

• 注册一个 Github 的帐号
• 建立一个 Github 项目主页

而更高级的全球化 "码农" 社交，还至少须要以下动做：

• Watch一个大牛的项目，时刻关注动态，紧跟步伐
• Fork一个项目，本身修改，成为社区贡献者

下面将以 Github 对具体对象，来说解如何使用git工具来

3   项目内容

• 可正常运行源代码
• 项目简介文档-ReadMe

本文将以一个 Github 开源项目为例子进行简单讲解。

本文 GitHub 项目示例

gt-java-sdk

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 项目以后，而后就是不断地往里面添加新特性，迭代维护了。

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

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" ，遵照这些工做流，对规范我的开发习惯或者增强团队协做效率都是极其有帮助的。

6   总结

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

在熟悉了git/github以后，我的能够获得以下改变：

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

但愿更多的软件版本管理的初学者们可以尽快的养成良好的版本管理系统和高效的版本管理手段，别的不说，至少有一点很是重要的做用就是：

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

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

---

做者:	Harmo哈莫
做者介绍:	https://zhengwh.github.io
技术博客:	http://www.cnblogs.com/beer
Email:	dreamzsm@gmail.com
QQ:	1295351490
时间:	2015-10
版权声明:	欢迎以学习交流为目的读者随意转载，可是请 【注明出处】
支持本文:	若是文章对您有启发，能够点击博客右下角的按钮进行 【推荐】