第二章:软件的生命周期,配置管理以及Git的使用指南

软件开发生命周期

从无到有的流程

在这里插入图片描述
然后从有到好
在这里插入图片描述
例如Windows系统的开发和演变
在这里插入图片描述

传统的软件过程模型

两个基本过程:
线性过程
迭代过程
现在一般采用的过程有:
瀑布过程
增量过程
V字模型
原型过程
螺旋过程
而选择合适的过程模型的依据有:

  1. 用户参与程度有多大?–适应变化的能力
  2. 开发效率/管理复杂度
  3. 开发出的软件的质量

瀑布过程

瀑布过程:
• 线性推进
• 阶段划分清楚
• 整体推进
• 无迭代
• 管理简单
• 无法适应需求
增加/变化

在这里插入图片描述
软件开发步骤被看作是在构思、启动、分析、设计、建造、测试、实施和维护等阶段稳步向下(就像瀑布一样)。

增量过程

增量过程:
• 线性推进
• 增量式(多个瀑布的串行)
• 无迭代
• 比较容易适应需求的增加

在这里插入图片描述

V字模型

V模型代表了一个开发过程,可以被认为是瀑布模型的扩展。
V字模型与前面的软件开发步骤不同的是不以线性的方式向下移动,过程步骤在编码阶段后向上弯曲,形成典型的V形并演示开发生命周期的每个阶段与其相关测试阶段之间的关系。 水平轴和垂直轴分别表示时间或项目完整性(从左到右)和抽象级别(最粗的粒度抽象)。

在这里插入图片描述

原型过程

原型过程带来的好处有:

  1. 软件设计者和实施者可以在项目早期从用户那里得到有价值的反馈。
  2. 客户端可以比较所制作的软件是否符合软件规范,根据该规范构建软件程序。
  3. 它还使软件工程师能够洞察初步项目估计的准确性,以及评估是否能够成功地在最后期限之前完成并达到之前设定的里程碑。
    原型过程采取迭代:开发出来之后由用户试用/评审,发现问题反馈给
    开发者,开发者修改原有的实现,继续交给用户评审。循环往复这个过程,直到用户满意为止。所以时间代价高,但开发质量也高。
    在这里插入图片描述

螺旋过程

在这里插入图片描述
螺旋过程是一种风险驱动的过程模型。
这是一种非常复杂的过程:
• 多轮迭代基本遵循瀑布模式
• 每轮迭代有明确的目标,遵循“原型”过程,进行严格的风险分析,方可进入下一轮迭代。

敏捷开发

敏捷开发:通过快速迭代和小规模 的持续改进,以快速适应变化。
敏捷宣言: 第一次创造于2001年,由17位著名的“程序员”创造”
在这里插入图片描述
Agile = 增量 + 迭代
每次迭代处理一个小规模增量

在这里插入图片描述
它的特点是:

  1. 极限的用户参与
  2. 极限的小步骤迭代
  3. 极限的确认/验证
    在这里插入图片描述
    我的感觉是敏捷开发是一种蚕食策略,把原本大量的工作拆成一小段一小段,然后逐渐解决这些小问题,以达到目标。

瀑布模型VS敏捷开发

在这里插入图片描述

敏捷开发方法:极限编程

在这里插入图片描述

敏捷开发方法:Scrum

在这里插入图片描述

软件配置管理(SCM)和版本控制系统(VCS)

SCM

软件配置管理是为了追踪和控制软件的变化,其核心在于版本控制和基线的确立。
在这里插入图片描述

配置项的生命周期

软件的任何组成部分(源代码、数据、文档、硬件、各种环境)都可以随着软件生命周期的时间而更新。软件配置项就指的是:软件中发生变化的基本单元(例如:文件)。

在这里插入图片描述

配置项(SCI)和基线

基线:软件持续变化过程中的“稳定时刻”(例如:对外发布的版本)
在这里插入图片描述

CMDB和签入/签出进行审核

CMDB:配置管理数据库
存储软件的各配置项随时间发生变化的信息+基线
在这里插入图片描述

版本控制

版本:为软件的任一特定时刻(Moment)的形态指派一个唯一的编号,作为“身份标识”。有一种古老的版本控制方法是通过复制文件并修改文件名。
对于个人来说,版本控制有以下的好处:

  1. 方便回滚到上一个版本。
  2. 方便比较两个版本的差异。
  3. 方便备份软件历史
  4. 方便获取备份。
  5. 方便合并。
    对于团队合作来说,版本控制可以:
  6. 在多个开发者之间共享和协作。
  7. 记录每个开发者的动作,便于“审计”。

版本配置项的历史展示

在这里插入图片描述

版本控制术语

仓库:即于SCM中的CMDB。
工作拷贝:在开发者本地机器上的一份项目拷贝。
文件:一个独立的配置项。
版本:在某个特定时间点的所有文件的共同状态。
变化:即code
churn,两个版本之间的差异。
HEAD:程序员正在其上工作的版本。

版本控制系统的特点

▪可靠:只要我们需要,就保留版本;允许备份。
▪多个文件:跟踪项目的版本,而不是单个文件。
▪有意义的版本:更改了什么,为什么是 你做的?
▪转换:恢复旧版本,全部或部分。
▪比较版本。
▪回顾历史:整个项目或个人文件。
▪不仅仅是代码:还包括散文,图像。
▪它应该允许多个人一起工作:
1. 合并:合并版本,与以前的通用版本不同
2. 跟踪责任:谁做了那个改变,谁碰了那一行代码?
3. 并行工作:允许程序员独自工作(并不放弃版本控制)
4. 正在进行的工作:允许多个程序员共享未完成的工作
5. 正在进行的工作:允许多个程序员共享未完成的工作(而不干 扰其他人,而不放弃版本COntrol)允许多个 程序员共享未完成的工作。

版本控制系统的三大类

本地版本控制系统:

仓库存储于开发者本地机器且无法共享和协作

在这里插入图片描述

集中式版本控制系统

仓库存储于独立的服务器,支持多开发者之间的协作
在这里插入图片描述

在这里插入图片描述

分布式版本控制系统:

仓库存储于独立的服务器+每个开发者的本地机器(git就是典型的分布式版本控制系统)。

在这里插入图片描述
在这里插入图片描述

以Git为例的单片机工具

管理软件进化过程中的变化

在这里插入图片描述

Git仓库

▪Git存储库有三个部分:
git目录:(存储所有版本控制数据的存储库)本地的CMDB
工作目录:本地文件系统-存储区域(内存)
暂存区:隔离工作目录和Git仓库
** 每个文件属于以下三种状态之一:**
已修改(工作目录中的文件与git存储库中的文件不同,但不在暂存区)-已暂存(文件被修改并已添加到暂存区)
已提交(文件在工作目录和Git目录中保持不变)已提交

在这里插入图片描述

Git中的对象图

Git的所有操作都是在一个图数据 结构(对象图)上进行,从另一台机器/服务器复制git项目意味着复制整个对象图。
git clone URL local_repository
Object Graph:版本之间的演化关系图,一条边 A->B表征了“在版本B的基础上作出变化,形成 了版本A”
在这里插入图片描述

提交:对象图中的节点

历史图中的每个节点都是提交得到的。 版本a。
项目修订:当时所有文件的完整快照。 -
除初始提交外,每个提交h作为指向父提交的指针。 每个commit指向一个父亲-有些提交具有相同的父级:它们是与以前的通用版本不同的版本。
多个commit指向同一个父亲:分支-有些提交有两个括号 ts:它们是将不同历史联系在一起的版本。
一个commit指向两个父亲:合并▪分支只是指向提交的名称。

▪HEAD指向当前提交。 我们需要记住 我们正在工作的CH分支。 因此HEAD指向当前分支,该分支指向当前提交。 Head指向了当前分支的当前commit。
Git表示具有树节点的提交。 对于任何合理大小的项目,大多数文件不会在任何给定的修订中更改。 存储文件的冗余副本是浪费的,所以 Git不会这么做。 相反,Git对象图将单个文件的每个版本存储一次,并允许多个提交共享该副本。 每个提交也有日志数据-谁,什么时候,短日志消息等。

管理Git中的更改

传统VCS存储版本之间的变化(行)

在这里插入图片描述

Git存储发生变化的文件(而非代码行), 不变化的文件不重复存储

在这里插入图片描述

Git的版本区分文件的变化:文件未发生变化,则后续多个版本始终指向同一个文件。文件发生变化了,存储两份不同的文件,两个版本指向不同的文件。

用git commit把本地文件添加到对象图中

在这里插入图片描述

用git push和git pull发送和接收对象图

在这里插入图片描述

基本的Git命令

跟踪新文件、暂存已修改文件

▪ 使用git add开始跟踪一个新文件(使某个文件纳入到git中管理)。
▪ 一个修改过的且被跟踪的文件,处于暂存状态。
▪ git add后面可以指明要跟踪的文件或目录路径。如果是目录的话,就
说明要递归跟踪该目录下的所有文件。
▪ git add的潜台词:把目标文件快照放入暂存区域,也就是 add file
into staged area,同时之前未曾跟踪过的文件标记为需要跟踪。
▪ 若对已跟踪的文件进行了修改,使用git add命令将其放入暂存区;
▪ 运行了git add之后又对相应文件做了修改,要重新git add。

检查当前文件状态

▪ 要确定哪些文件当前处于什么状态,用git status命令:
– # On branch master nothing to commit (working directory clean)
当前没有任何跟踪着的文件,也没有任何文件在上次提交后更改过
– # On branch master # Untracked files: …
有未跟踪的文件,使用git add开始跟踪一个新文件
– # On branch master # Changes to be committed:
有处于已暂存状态的文件

查看已暂存和未暂存的更新

▪ git status回答:当前做的哪些更新还没有暂存?有哪些更新已经暂存
起来准备好了下次提交?
▪ 如果要查看具体修改了什么地方,可以用git diff命令,使用文件补丁
的格式显示具体添加和删除的行。
▪ 要查看尚未暂存的文件更新了哪些部分,不加参数直接输入git diff: – 比较的是工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后
还没有暂存起来的变化内容。
▪ 若要查看已暂存起来的文件和上次提交时的快照之间的差异,可以
用 git diff --cached 命令

提交更新

▪ 在使用git commit命令进行提交之前,要确认是否还有修改过的或新
建的文件没有git add过,否则提交的时候不会记录这些还没暂存起来
的变化。
– 每次准备提交前,先用git status进行检查,然后再运行提交命令git commit。 ▪ 提交后返回结果:
– 当前是在哪个分支(master)提交的
– 本次提交的完整 SHA-1 校验和是什么
– 在本次提交中,有多少文件修订过、多少行添改和删改过。
▪ 提交时记录的是放在暂存区域的快照,任何还未暂存的仍然保持已修
改状态,可以在下次提交时纳入版本管理。每一次运行提交操作,都
是对项目做一次快照,以后可以回到这个状态,或者进行比较。

跳过使用暂存区域、移除文件

▪ Git提供了一个跳过使用暂存区域的方式,只要在提交的时候,给 git
commit 加上-a 选项,Git 就会自动把所有已经跟踪过的文件暂存起来
一并提交,从而跳过git add步骤;
▪ 使用git rm命令从Git中移除某个文件,把它从已跟踪文件清单(暂存
区域)中移除,并连带从工作目录中删除指定的文件。

对远程仓库的操作

▪ 远程仓库:托管在网络上的项目仓库;
▪ 多人协作开发某个项目时,需要管理这些远程仓库,以便推送或拉取
数据,分享各自的工作进展。
▪ 管理远程仓库:添加远程库、移除废弃的远程库、管理各式远程库分
支、定义是否跟踪这些分支。
– git remote:获取当前配置的所有远程仓库;
– git remote add [shortname] [url]:添加一个远程仓库;
– git fetch:从远程仓库抓取数据到本地;
– git pull: 从一个仓库或者本地的分支拉取并且整合代码;
– git push [remote-name] [branch-name]:将本地仓库中的数据推送到远程
仓库;
– git remote show [remote-name]:查看某个远程仓库的详细信息;
– git remote rm:从本地移除远程仓库

分支/合并

▪分支是在版本控制下对对象的复制,以便可以沿两个分支平行进行修改。
▪合并是指将两个分支融到一起。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值