前言
项目需要迭代
我们开发的应用程序是需要不断的迭代的,比如 version 1.0 、version 2.5 、version 3.9.11,这些指的都是版本号。
不同版本号的应用程序,里面的功能都是不一样的,比如我们做一个名字叫做 project1 的应用,v1.0时可能仅仅只是基础框架,v1.1时增加用户中心模块,然后用了一段时间出现了一个致命的bug,然后我们把 project1 升级到了 v1.1.1 解决了这个bug,所以说应用程序是需要不断的迭代的。
版本号规范
版本号有很多种规范,下面列出的是 Net Framework 风格版本号
主版本号.子版本号.修正版本号
- Major :主版本号。例如,对产品的大量重写,这些重写使得无法实现向后兼容性。
- Minor :子版本号。这指示显著增强,但照顾到了向后兼容性。例如,这适用于产品的修正版或完全向后兼容的新版本。
- Revision :修正版本号。这适用于修复以前发布的程序集中的安全漏洞。
版本管理
直接把项目复制出来一份,在副本项目中,直接做迭代,但这样做有一个坏处,如果升级的内容比较多,时间间隔又大的话,可能会忘记都做过什么事,这样就不便于管理了,所以应该选择一种更智能的方式管理我们的文件版本。
Git分布式版本控制系统
Git 的诞生
林纳斯·托瓦兹在1991年创建了开源的Linux,Linux系统已经发展了十年了,代码库之大让林纳斯很难继续通过手工方式管理了,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错!),于是BitMover公司怒了,要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。实际情况是这样的:
Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linux系统的源码已经由Git管理了!
集中式 vs 分布式
SVN集中式:版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。
GIT分布式:分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。
Git的三棵树
-
工作区:我们编写代码的文件环境。
-
暂存区:临时存储区域。
-
版本库:代码仓库,即分支。文件最终保存的区域。
安装 Git
mac 自带 git,windows 需要安装 git。
git --version // git version 2.23.0.windows.1
安装完成后,还需要最后一步设置,在命令行输入:
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
使用git config user.name或git config user.email可以查看用户名和邮箱。
创建版本库
理解成这个目录里面的所有文件都可以被Git管理起来。
创建一个文件夹repo1,命令行进入到这个文件夹。(可以忽略)
# mkdir repo1 # 创建repo1目录
cd repo1 # 进入到repo1目录
# pwd # 显示当前目录的路径
# ls # 显示当前目录的内容
然后把这个目录变为 Git 可以管理的目录
git init # git初始化
不报错就是创建成功
把文件添加到代码仓库
在 repo1 这个文件夹里,创建一个名字叫做 a.txt 的文件。里面写点内容,比如写111。
# touch 是linux中创建文件的命令,如果不习惯,也可以右键新建文件创建a.txt
touch a.txt # 在当前目录下创建 a.txt 文件,如果装了xcode,可以用 open a.txt -a xcode 来编辑文件
add:工作区->暂存区
第一步,用命令git add告诉Git,把文件添加到仓库
git add a.txt
命令 | 描述 |
---|---|
git add . | 这表示提交所有有变化的文件 |
git add abc | 这表示提交abc这个文件夹 |
git add *.js | 这表示提交所有js文件 |