Git对于大家应该是很熟悉的,
分布式管理,比SVN更容易管理自己的项目,
可以通过命令操作,
或者借助于工具来使用,
如果让你阐述什么是Git?或者Git讲解,就会难以启齿,你真的懂Git吗?
Git使用
- 命令
- git clone
- git pull
- git log
- git add
- git commint
- git push
- ……
- 分支管理
- 新功能分支
针对每一个功能所需要创建的分支,可以是一个版本的功能分支,也可是同一个版本的不同功能分支,总而言之,就是整拆零,零合整; - 解决BUG分支
上次发包时用户反馈的、捕获的、测试新提出的BUG,这个BUG可以是长期的(一时半会搞不定),或者短期必须解决的; - 优化分支
如果问你开发一个项目需要多少时间,有的人会说“计算设计在内的话,可能也就几个月时间吧……”,这个只是第一版本,也可以理解为初级版本,优化无处不在,开发一代版本很容易,但是你真的做的够好吗?还是简简单单的为了任务时间造成的冗杂代码,或者有更好的实现方式,今天看昨天的代码你会发现看不上眼,有的人觉得整天好闲好闲,任务完成了就没什么事情做了,或者公司领导不安排其他事情就觉得“我还真是个人才,完成任务,不拖不耗”,往往都是自己害了自己; - 不同标签的分支
标签是什么?就是在当前节点标记一个记录,还是那句话“提供容错率”,俗话说:“一个好项目不是写出来的,是测出来的”,为什么这么理解?
举个栗子:一个项目可以理解为一个圆(无数个小圆点组合成的整体),第一版本或者开发完成阶段,就像10几个点组成一个圆形,现在如果用针穿过这个圆的概率是多少呢?答案是:86.9%;现在开始提测试,包括测试人员,自测等等之后呢,这个圆形现在是由1000个点组成的,现在用针穿过这个圆形的概率会是多少呢?答案显而易见的,肯定远远低于86.9%;
同时开发不同的需求,不确定性是否上线?或者时间断点不一致,不能同时发布
- 新功能分支
- 标签管理
- 版本?1.0.0,1.0.1……
每发布一个新版本要对旧版本做一下标签,每一个重要功能也尽量做一个标签记录,不要问为什么,时间会证明一切!!! - 功能备注
每个不同的功能创建一个分支,随时可以切换分支,丢弃code - 插入需求
开发阶段需求方提供一个不确定性的需求,尝试开发(或许开发完成之后更换掉); - 回退代码
上线前发现一个不可逆操作,或者一些功能砍掉,如何更快速的稳定操作(代码不丢失,丢掉不需要的code);
- 版本?1.0.0,1.0.1……
- 代码合并操作
- 分支合并
- 为什么合并分支
为了减少测试人员人工耗时,需要把发布前分支全部合并成一个新的临时分支(临时分支:发布之后需要删掉,可以随时丢掉的分支) - 如何合并?
- 功能
- 上线的优化
- BUG
- 为什么合并分支
- 分支合并
- 协同开发
- 合并?
- Marge?Rebase?此处烧脑,后续讲解
- 合并?
- 如何快速解决问题?
- 如何使容错率更高?
这里插入一张图更容易理解:
后续持续更新!!!