版本控制— SVN & git

时间:2023-09-03 08:34:38

版本控制—— SVN & GIT

提问

什么是版本控制?

是能够一直监视代码文件的变更,并存储这些文件以便将来引用的一种机制(软件)

为什么要使用版本控制?

(1)记录哪个开发人员做了变更
(2)变更发生的具体时间
(3)实际修订的内容
(4)如果需要,可以恢复特定文件或者整个项目到以前的版本
(5)……

不使用版本控制还会出现什么问题?

不使用版本控制可能出现的问题

1.备份多个版本,费空间,费时间
2.难于恢复至以前正确版本
3.容易引发BUG
4.解决代码冲突困难
5.代码管理混乱
6.难于追溯问题代码的修改人和修改时间
7.项目版本发布困难
8.……

版本控制(Revision Control)

是维护工程蓝图的标准做法,能追踪工程蓝图从诞生一直到定案的过程。是一种记录若干文件内容变化,以便将来查阅特定版本修订情况的系统

现在就开始使用版本控制

如果是开发团队中的一员,使用版本控制是强制性的!

如果是单人开发,也强烈建议现在就开始使用版本控制

使用版本控制可以:

(1)不会对现有工作造成任何损害
(2)不会增加工作量
(3)添加新的功能拓展时,会变得更加容易

版本控制工具

1.CVS  开启版本控制之门
2.SVN  集中式版本控制之王者
3.GIT  分布式版本控制之伟大作品

SVN

1.SVN简介
2.SVN服务器端安装
3.SVN客户端软件
4.SVN与Xcode的集成

SVN基本交互流程图

SVN服务器安装

VisualSVN-Server

到公司,管理员建立用户名&密码,然后告知svn的地址

http: 80

https: 443

Subversion目录规范

1./trunk   存放开发的“主线”
2./branches   存放支线副本
3./tags   存放标签副本(版本标记1.0, 2.0)

SVN客户端软件

1.Cornerstone
2.Versions (注意:添加了Bookmark之后,需要重新启动一下Versions!)

有了Xcode,为什么还要使用客户端软件?

²因为Xcode对SVN的集成做的不够好,尤其在目录管理方面必须要小心谨慎!

SVN复习

服务器:代码仓库

协议头:

http: 80   不勾选

https: 443   勾选安全

服务器上选中服务器,点击右键,选择”properties(属性)”network(网络)

客户端:Versions

1. Repository Bookmark书签,代码仓库的标签

2. SVN的一个代码仓库中可以放多个项目

3. 用客户端最大的目的就是辅助检查是否有遗漏的情况

大部分工作在Xcode中都可以完成

Xcode工作:先更新,再提交!

Xcode中,最好不要多人同时修改一个Storyboard!

注意!!!

.svn这个隐藏目录记录着两项关键的信息

(1)工作文件的基准版本
(2)一个本地副本最后更新的时间戳

注意:千万不要手工修改或删除这个 .svn隐藏目录和里面的文件! 否则将会导致本地的工作副本被破坏,无法再进行操作

SVN与Xcode集成演练

1.利用多个客户端模拟多人协同工作
2.解决代码冲突
3.多人编译同一个Storyboard(谨慎)
4.新建分支并合并回主线

关于分支的细节:

(1)分支中开发的代码,要尽可能与主杆Trunk上的代码耦合度低!

使用SVN我们应该

1.经常更新:降低冲突的可能性
2.提交前需在本机测试通过:降低将问题代码传到版本库
3.提交时一定写备注:方便其他员工查看和自己以后回顾
4.对于不需要提交的文件不要提交到版本库

提示

1.每次提交之前先更新
2.每天下班前提交当天编译通过的代码
3.每天上班第一件事情更新前一天的代码

GIT

1.GIT简介
2.GIT工作模型及基本概念
3.GIT常用命令及演练
4.在Xcode中使用GIT
5.GIT经典协同模型/分支分类
6.GIT服务器的安装与配置

GIT简介

GIT是一款*和开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目

是Linus(李纳斯)的第二个伟大作品,2005年由于BitKeeper软件公司对Linux社区停止了免费使用权。Linus迫不得己自己开发了一个分布式版本控制工具,从而Git诞生了

几乎所有优秀的iOS第三方框架都使用GIT

目前移动开发领域,越来越多的公司开始转向GIT

Xcode中已经集成了最常用的GIT功能

SVN vs GIT

SVN

集中式

效率略差

国内使用的较为广泛

由较好的图形化客户端和服务器支持,学习和使用相对简单

项目分支管理简单

GIT

分布式

效率高

国际上已经普遍使用,移动互联网项目开始越来越多地转向GIT

Xcode集成的功能已经能够满足大部分日常需求,但还有少量命令需要在终端输入,学习曲线相对陡峭

项目分支可以无限细分,更适合大型项目的版本规划

选择GIT的理由

1.分布式,离线操作
2.每日工作备份
3.异地协同工作
4.现场版本控制
5.避免引入辅助目录
6.可以吃后悔药
7.工作进度随时保存
8.快

GIT工作模型

1.集中式协同模型
2.社交网络式协同模型

集中式协同模型

社交网络式协同模型

GIT基本交互流程图

GIT仓库初始化

仓库初始化

git init --bare shared.git

仓库文件目录

HEAD:  指向当前分支的一个提交

description:  项目的描述信息

config:  项目的配置信息

info/:  里面有一个exclude文件,指定本项目要忽略的文件

objects/:  Git对象库(commit/tree/blob/tag)

refs/:  标识每个分支指向哪个提交

hooks/:  默认的hook脚本

GIT设置配置信息

命令

git config -l   查看配置信息

git config -e   编辑配置信息

默认修改.git/config文件

个人信省息初始化(不要随意修改)

git config user.name "user01"

git config user.email "user01@163.com"

提示:如果没有配置全局信息,每次克隆之后都必须配置用户名和邮件!

使用--global参数可以配置全局个人信息

忽略无需版本控制的文档

echo “*.txt” > .gitignore

GIT基本命令

工作区、暂存区和代码区

GIT命令行演练

1.创建代码仓库
2.多人协同工作
3.解决冲突
4.删除无需版本控制的文档

Xcode演练

1.创建代码仓库
2.多人协同工作
3.解决冲突
4.多人同时修改Storyboard
5.删除无需版本控制的文档

.gitignore中的内容

.DS_Store

*.xcworkspace

GIT经典协同模型

中心仓库:包含master和develop两个分支

分支分类

(1)主要分支:master和develop分支
(2)支持性分支:特性分支,发布分支,热补丁分支

提示:

(1)对于商业级项目,真正开发过程中都是基于develop分支进行的,develop分支是开发主线!
(2)master分支中,只存放相对稳定的分支,例如:0.1版本, 0.2版本
(3)在实际产品开发中,需要“规划版本”,例如:将100个功能规划到5个不同的版本上
(4)发现bug,要基于“上一个最稳定的版本”进行修复,这是热补丁分支存在的意义!
(5)理解清楚版本管理分支的特性,是迭代式开发的重要基础!

给分支打标签

git tag -a v1.0 -m 'Version 1.0'

打一个1.0的标签

git push origin v1.0

将标签推送到远程服务器

git tag

查看当前标签

git checkout v1.0

签出v1.0标签

git checkout -b v1.0hotfix

签出并创建v1.0hotfix分支

git branch

查看当前所在分支

安装GIT服务器

GIT代码仓库本质上是通过命令行来操作的

如果在局域网中配置GIT服务器,只要能够通过终端访问到服务器即可

在Windows上要安装GIT服务器,安装如下三个软件即可

(1)CopSSH  允许windows使用ssh访问unix服务器目录

注意:CopSSH的用户一定不能是windows的管理员!!!

(2)GIT-Windows  在Windows中运行的GIT,其本质就是命令行
(3)Tortoisegit  Windows中GIT的图形化操作客户端

在Mac上要安装GIT服务器,无需安装任何软件,只需要设置访问用户即可,远程用于通过授权的账户名和密码登录,即可使用GIT

提示:GIT服务器可以是互联网中的某台主机,也可以是局域网中的某台计算机的共享目录,还可以是U盘。总之:分布无所不在!

CopSSH

将Git\libexec\git-core下的git.exe
, git-receive-pack.exe, git-upload-archive.exe, git-upload-pack.exe拷贝到\ICW\bin下

将\Git\bin\libiconv-2.dll拷贝到ICW\bin下

CopSSH本质上就是允许其他计算机以SSH的方式访问计算机资源

SSH是目前较可靠的,专为远程登录会话和其他网络服务提供安全性的协议

使用GIT我们应该

1.经常更新:降低冲突的可能性
2.提交前需在本机测试通过:降低将问题代码传到版本库
3.提交时一定写备注:方便其他员工查看和自己以后回顾
4.对于不需要提交的文件不要提交到版本库

提示

1.每次提交之前先更新
2.每天下班前提交当天编译通过的代码
3.每天上班第一件事情更新前一天的代码

Q & A

如果你现在是开发团队中的一员,还是单人开发,都强烈建议现在就开始使用版本控制!