一、版本控制

1.1、什么是版本控制

    版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
    在公司中,一般以团队的形式进行项目的开发。在一个团队中,每一个团队成员都需要一份相同的代码,而大家又都基于这份代码去开发着不同的功能,过程中就会产生相当多的问题,针对这些问题,我们可以采用版本控制的方式来解决,也因此诞生了很多的版本控制工具,如市面上比较常见的 cvs/svn/git 等等。

1.2、为什么要有版本控制

    有了它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某
个时间点的状态。就算你乱来一气把整个项目中的文件改的改删的删,你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
    你可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致怪异
问题出现的原因,又是谁在何时报告了某个功能缺陷等等。
    版本控制深入程序员在团队配合中,如果你的项目没有版本控制:

  1. 代码管理混乱。
  2. 解决代码冲突困难。
  3. 在代码整合期间引发BUG。
  4. 无法对代码的拥有者进行权限控制。
  5. 项目不同版本发布困难。

1.3、版本控制工具分类

    目前市面上主要有两种类型的版本控制工具:

  1. 集中化的版本控制系统
  2. 分布式的版本控制系统

1.3.1、 集中化的版本控制系统

    集中化的版本控制系统诸如 CVS,svn 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。

image-20210404120152628
    这种做法带来了许多好处,现在,每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个集中化的版本控制系统; 要远比在各个客户端上维护本地数据库来得轻松容易。
    事分两面,有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。同时他必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟。

1.3.2、分布式的版本控制系统

    于是分布式版本控制系统面世了。在这类系统中,像 Git,BitKeeper 等,客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份。

image-20210404120613873
    分布式的版本控制系统在管理项目时 存放的不是项目版本与版本之间的差异.它存的是索引(所需磁盘空间很少 所以每个客户端都可以放下整个项目的历史记录)
    和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。
    在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

1.4、Git简史

    Git 是目前世界上最先进的分布式版本控制系统。同生活中的许多伟大事件一样,Git诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间)。到 2002 年,整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。
    到了 2005 年,开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结
束,他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区(特别是 Linux的缔造者 Linus Torvalds )不得不吸取教训,只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。
    自诞生于 2005 年以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。它的速度飞快,极其适合管理大项目,它还有着令人难以置信的非线性分支管理系统可以应付各种复杂的项目开发需求。

二、Git的安装

2.1、在Windows上安装

    Git的官网Windows版本,下载完安装包之后,双击 exe 安装包,进行安装。

image-20210404121325510

图片 10_2

图片 10_2

    完成安装之后,就可以使用命令行的 git 工具(已经自带了 ssh 客户端)。在桌面或者任意文件夹的空白位置右键,出现下图所示的这个菜单栏即表示安装成功。

image-20210404121507806

    当你点击 git bash Here 菜单之后,可以看到一个终端窗口,在终端里面输入命令 就可以查看到版本信息。

git --version

image-20210404121723709

2.2、在Mac上安装

    Git的官网Mac版本,下载下来之后可以看到一个 dmg 文件,双击打开 压缩文件,可以看到里面有一个文件, 再次双击 pkg 文件,就可以进行安装,然后按照引导一直点击继续按钮就可以完成安装了。

三、Git初始化

3.1、Git初始化配置

    因为Git是分布式版本控制系统,所以,每个机器都必须自报家门:你的名字Email地址。这两条配置很重要,每次 Git 提交时都会引用这两条信息,说明是谁提交了更新,所以会随更新内容一起被永久纳入历史记录。我们可以在Git命令行输入两条命令进行配置:

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

    要检查已有的配置信息,可以使用 如下命令:

git config --list 

3.2、初始化仓库

    要对现有的某个项目开始用 Git 管理,只需到此项目所在的目录,执行:

git init

    执行完后我们可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的。所有 Git 需要的数据和资源都存放在这个目录中。不过目前,仅仅是按照既有的结构框架初始化好了里边所有的文件和目录,但我们还没有开始跟踪管理项目中的任何一个文件。

3.3、.git目录详解

image-20210404122800857

  1. hooks 目录包含客户端或服务端的钩子脚本;
  2. info 包含一个全局性排除文件
  3. logs 保存日志信息
  4. objects 目录存储所有数据内容;
  5. refs目录存储指向数据的提交对象的指针(分支)
  6. config 文件包含项目特有的配置选项
  7. description用来显示对仓库的描述信息
  8. HEAD 文件指示目前被检出的分支
  9. index 文件保存暂存区信息

四、Git的使用

4.1、使用git命令将文本添加到版本库中

    在添加之前先做一个标记操作。实际上是先将文件添加到缓存区, 然后再添加到版本库。
    先使用命令告诉Git:把文件交给 Git 进行管理

git add

    然后再告诉Git,把文件提交到本地仓库

git commit -m "wrote a readme file"

    -m后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。git commit命令执行成功后会告诉你,1个文件被改动(我们新添加的readme.txt文件),插入了两行内容(readme.txt有两行内容)。

    在执行 commit 之前,都先执行一下 add 操作,避免有文件被漏掉了

4.2、工作区和暂存区

    在git中进行 crud 操作时都需要执行 git add 文件这个操作,底层操作将操作文件添加一个叫缓存区区域中缓存,当操作完毕之后,使用 git commit 操作,进行统一提交,将编辑文件统一同步版本中。

图片 33_2

图片 34_2

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-igqUf3nC-1620290751987)(G:\叩丁狼\高级框架\4、Git\资料\images\git\图片 35.png)]

4.3、查看版本库状态

    如何查看项目目前的状态?我在电脑前写了一段时间代码,用Git管理,中途上厕所,然后又去吃了个苹果,继续回来工作,不记得之前用Git干了些什么了?

# 查看当前git版本库的状态(查看缓存区中的文件内容)
git status 

图片 26_2

4.4、查看日志

    我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容,所以版本控制系统肯定有某个命令可以告诉我们历史记录

git log

图片 22_2

    git log 命令显示从最近到最远的提交日志,如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数:

git log --pretty=oneline

图片 23_2

    我们可以看到,commit id 是一串长长的字符,而不是数字,原因是因为当两个人同时在一个代码上工作时候,分别往各自的本地的版本库提交时,相同的提交号对应着不同的修改,如果使用1,2,3这样的数字不能保证唯一性,所以Git使用SHA-1算法产生唯一标识符,保证全球唯一
    比如程序员甲和乙负责共同开发一个聊天软件,使用Git来版本控制。 Git是分布式版本控制,每个人都有一个版本库。如果Git版本控制用1,2,3这样的数字来生成版本号,那么程序员甲和乙代码合并的时候就会出现问题。版本1到底是谁的?
    SVN 是集中式的版本控制,只有一个版本库,所以版本号可以从1,2,3开始。Git是分布式版本控制,每个人都有一个版本库,所以不能从1,2,3开始。

4.5、查看差异

    如果一个文件知道被人修改了,但如果能看看具体修改了什么内容,自然是更好的
比如你休假两周从国外回来,第一天上班时,已经记不清上次怎么修改的readme.txt,所以,需要用git diff这个命令看看:

# 查看不同版本之间的文件差异
git diff 

4.6、版本回退

    每当你觉得文件修改到一定程度的时候,就可以**“保存一个快照”**,这个快照在Git中被称为 commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit 恢复,然后继续工作,而不是把几个月的工作成果全部丢失。

    Git必须知道当前版本是哪个版本,在Git中,用HEAD表示当前版本,上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100

    如果我们要把当前版本回退到上一个版本,就可以使用git reset命令:

git reset --hard HEAD^

图片 30_2

    回到指定版本

git reset --hard <commit id>

图片 31_2

4.7、撤销修改

    git checkout -- filename可以丢弃工作区的修改:– 后面是一个空格,比如:

git checkout -- readme.txt

    这个命令的意思是说把readme.txt文件在工作区的修改全部撤销,这里有两种情况:

  1. readme.txt 自修改后还没有被放到暂存区(git add),现在,撤销修改就回到和版本库一模一样的状态;
  2. readme.txt 已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。

    总的来说就是让这个文件回到最近一次 git commitgit add 时的状态。

    git checkout -- file 命令中的 -- 很重要,没有 -- ,就变成了“切换到另一个分支”的命令。

4.8、删除文件

    一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm命令删了:

git rm test.txt

4.9、分支管理

    Git 拥有强大的分支管理系统,且推荐在项目开发过程中大量的使用分支来解决各种项目中的问题。

image-20210426181502639

4.9.1、查看分支

    我们可以使用命令去查看当前分支。

git  branch

图片 45_2

4.9.2、创建分支

    我们可以使用命令去创建分支。

git  branch 分支名字

图片 46_2

4.9.3、切换分支

git checkout 分支名字

4.9.4、创建+切换分支

git checkout -b 分支名字

4.9.5、合并到当前分支

git merge 分支名

4.9.6、删除分支

git branch -d 分支名

五、推送远程仓库命令

  1. 初始化本地的仓库
git init
  1. 设置码云的用户名跟码云注册邮箱
git config --global user.name "码云里面用户名"
git config --global user.email "码云里面注册邮箱/手机"
  1. 配置忽略提交的文件.gitignore

  2. 将项目添加到本地仓库

git add .
git commit -m "项目初始化"
  1. 配置远程仓库请求路径
git remote add origin 自己在码云创建仓库路径
  1. 将本地仓库中crm项目推送到远程仓库
git push -u origin master
  1. 弹出一个框, 输入码云账号与密码

六、团队开发注意事项

  1. 组员每次开发,都先 push 到自己的远程分支
  2. 每次对 master 分支做合并或推送之前,原地备份代码
  3. 确保自己分支的代码与 master 分支都没有错误以后,将本地 master 推送到远程
  4. 开发前,先切换到 master 分支,更新代码,确保是最新版本,如果有更新下来内容,同样先对整个项目进行备份,再切换到自己的分支,然后将 master 合并到自己的分支上
  5. 除了将代码提交到自己的分支以外,都必须再将自己的代码合并到master
  6. 再次强调,每次合并或推送前,都先对项目进行备份,避免操作不熟练导致出错后代码丢失

码云开发流程

Logo

瓜分20万奖金 获得内推名额 丰厚实物奖励 易参与易上手

更多推荐