文章目录
1.软件构造的生命周期
From 0 to 1 :
From 1 to n:
2.传统的软件构造过程
线性过程:
迭代过程:
模型:
– Waterfall (Linear, non-iterative) 瀑布过程
– Incremental (non-iterative) 增量过程
– V-Model (for verification and validation) V字模型
– Prototyping (iterative) 原型过程
– Spiral (iterative) 螺旋模型
需要根据用户的参与度,开发效率,管理复杂度,开发出软件的质量来选择使用什么模型。
瀑布模型介绍:
线性推进-阶段划分清楚-整体推进-无迭代-管理简单-无法适应需求变化
增量过程介绍:
迭代模型:
迭代:开发出来之后由用户试用/评审,发现问题反馈给
开发者,开发者修改原有的实现,继续交给用户评审。
循环往复这个过程,直到用户满意为止。时间代价高,但开发质量也高。
非常复杂的过程:
• 多轮迭代基本遵循瀑布模式
• 每轮迭代有明确的目标,遵循“原型”过程,进行严格的风险分析,方可进入下一轮迭代
3.敏捷开发
通过快速迭代和小规模的持续改进,以快速适应变化。
敏捷=增量+迭代,每次迭代出来了一个小的规模增量
用户可以最大程度参与开发过程,确认和验证
4.软件配置管理(SCM)和版本控制系统(VCS)
软件在开发过程中需要不断修改不断迭代,软件配置管理即追踪和控制软件的变化
版本:为软件的任一特定时刻(Moment)的形态指
派一个唯一的编号,作为“身份标识”
古老的版本控制方法:通过复制文件并修改文件名
为什么需要版本管理:
比较不同版本间的差异
备份历史版本
获得备份
合并,多个开发者之间共享和合作
记录每个开发者的修改,便于“审计”
基线:软件持续变化过程中的“稳定时刻”(例如:对外发布的版本)
CMDB:配置管理数据库存 储软件的各配置项随时间发生变化的信息+基线
仓库:项目中版本的本地或远程存储空间
工作拷贝:在开发者本地项目上的一份项目拷贝
文件:一个独立的配置项
版本:在某个特点时间点的所有文件的共同状态
变化:即两个版本之间的差异
HEAD:正在操作的版本
本地版本控制系统:仓库存储于开发者本地机器,无法共享和协作。
集中式版本控制系统:仓库存储于独立的服务器,支持开发者之间的协作
分布式版本控制系统:仓库存储于独立的服务器+每个开发者的本地机器
5.Git as an example of SCM tool
Git由三部分组成
git directory (a repository storing all version control data) 本地的CMDB
Working directory (local file system) 工作目录:本地文件系统
** Staging area** (in memory) 暂存区:隔离工作目录和Git仓库
每一个文件属于以下三种状态之一
Modified (the file in working directoryis different from the one in git repository,but is not in staging area) 已修改
Staged (the file is modified and has been added into the staging area) 已暂存
Committed (the file keeps same in working directory and git directory) 已提交
我们用Git做的所有操作——克隆,添加,提交,推送,日志,合并,…-
是对一个存储项目中文件的所有版本的图数据结构的操作,以及所有描述这些更改的条目日志。
Git对象图存储在存储库的. Git目录中。
从另一台机器/服务器复制git项目意味着复制整个对象图。
每一个commit指向一个父亲
多个commit指向一个父亲:分支关系,如:82e049e和6400936指向1255f4e
一个commit指向两个父亲:合并关系,如:3e62e60指向82e049e和6400936
(可以有0 1 2 个 父对象 多个子对象)
HEAD points to the current commit. 我们需要记住我们在研究哪个分支。所以头指向当前分支,该分支指向当前提交。
对于任何合理大小的项目,大多数文件都不会更改
储存冗余的文件副本是很浪费的,所以Git不会这样做。
相反,Git对象图只存储单个文件的每个版本一次,允许多个提交共享同一个副本,即指针指向。
每个提交也有日志数据:谁、何时、短日志消息等。