一、版本控制
1. 概念
- 版本控制的英文是 Version control
- 是维护工程蓝图的标准作法,能追踪工程蓝图从诞生一直到定案的过程
- 版本控制也是一种软件工程技巧,借此能在软件开发的过程中,确保由不同人所编辑的同一程序文件都得到同步
版本控制在软件开发中,可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作
2. 功能
01 - 不同版本的存储管理
- 一个项目会不断进行版本的迭代,来修复之前的一些问题、增加新的功能、需求,甚至包括项目的重构
- 如果我们通过手动来维护一系列的项目备份,简直是一场噩梦
02 - 重大版本的备份维护
- 对于很多重大的版本,我们会进行备份管理
03 - 恢复之前的项目版本
- 当我们开发过程中发生一些严重的问题时,想要恢复之前的操作或者回到之前某个版本
04 - 记录项目的点点滴滴
- 如果我们每一个功能的修改、bug的修复、新的需求更改都需要记录下来,版本控制可以很好的解决
05 - 多人开发的代码合并
- 项目中通常都是多人开发,将多人代码进行合并,并且在出现冲突时更好的进行处理
3. 历史
01 - 版本控制的史前时代(没有版本控制)
- 人们通常通过文件备份的方式来进行管理,再通过diff命令来对比两个文件的差异
02 - CVS(Concurrent Versions System)
- 第一个被大规模使用的版本控制工具,诞生于1985年
- 由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的,也算是SVN的前身(SVN的出现就是为了取代CVS的)
03 - SVN(Subversion)
- 因其命令行工具名为svn因此通常被简称为SVN
- SVN由CollabNet公司于2000年资助并发起开发,目的是取代CVS,对CVS进行了很多的优化
- SVN和CVS一样,也属于集中式版本控制工具
- SVN在早期公司开发中使用率非常高,但是目前已经被Git取代
04 - Git(Linus的作品)
- 早期的时候,Linux社区使用的是BitKeeper来进行版本控制
- 但是因为一些原因,BitKeeper想要收回对Linux社区的免费授权
- 于是Linus用了大概一周的时间,开发了Git用来取代BitKeeper
- Linus完成了Git的核心设计,在之后Linus功成身退,将Git交由另外一个Git的主要贡献者Junio C Hamano来维护
4. 集中式版本控制
01 - 概念
- CVS和SVN都是是属于集中式版本控制系统(Centralized Version Control Systems,简称 CVCS)
- 它们的主要特点是单一的集中管理的服务器,保存所有文件的修订版本
- 协同开发人员通过客户端连接到这台服务器,取出最新的文件或者提交更新
02 - 优点
相较于老式的本地 管理来说,每个人都可以在一定程度上看到项目中的 其他人正在做些什么
03 - 缺点
是集中式版本控制有一个核心的问题:中央服务 器不能出现故障
- 如果宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作
- 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据
5. 分布式版本控制
Git是属于分布式版本控制系统(Distributed Version Control System,简 称 DVCS)
- 客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录
- 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复
- 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份
集中式版本控制 : 将仓库放到服务器,一旦服务器崩溃可能会导致代码及记录都消失
分布式版本控制 : 通过git clone把仓库完全镜像到本地,就算服务器出现问题也没有关系,记录和代码会在本地仓库保存一份,提交到远程仓库时会进行同步刷新
二、准备 Git
1. 安装
git : Git - Downloads
2. Bash – CMD – GUI 区别
- Bash,Unix shell 的一种,Linux 与 Mac OS X 都将它作为默认 shel- Git Bash 就是一个 shell,是 Windows 下的命令行工具,可以执行 Linux 命令- Git Bash 是基于 CMD 的,在 CMD 的基础上增添一些新的命令与功能- 所以建议在使用的时候,用 Bash 更加方便
- Git CMD- 命令行提示符(CMD)是 Windows 操作系统上的命令行解释程序- 当你在 Windows 上安装 git 并且习惯使用命令行时,可以使用 cmd 来运行 git 命令
- Git GUI- 基本上针对那些不喜欢黑屏(即命令行)编码的人- 它提供了一个图形用户界面来运行 git 命令
3. Git 的配置分类
Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量
01 - 仓库的通用配置
地址 : /etc/gitconfig => 包含系统上每一个用户及他们仓库的通用配置
- 如果在执行 git config 时带上--system选项,那么它就会读写该文件中的配置变量
- 由于它是系统配置文件,因此你需要管理员或超级用户权限来修改它
- 开发中通常不修改
02 - 针对当前用户,所有的仓库生效
地址 : ~/.gitconfig => 只针对当前用户
- 可以传递--global 选项让 Git 读写此文件,这会对你系统上所有的仓库生效
03 - 针对该仓库
地址 : 当前使用仓库的 Git 目录中的 config 文件,即.git/config => 针对该仓库
- 可以传递 --local 选项让 Git 强制读写此文件,虽然默认情况下用的就是它
4. Git 的配置选项
设置Git的 用户名和邮件地址
01 - 设置用户名
git config --global user.name 'coderstar'
02 - 设置邮箱
git config --global user.email'[email protected]'
03 - 检测配置信息
git config --list
5. Git的别名(alias)
如果不想每次都输入完整的 Git 命令
可以通过 git config 文件来轻松地为每一个命令设置一个别名
命令 : git checkout
设置别名 : git config --global alias.co checkout
使用 : git co
三、Git 操作本地仓库
1. 获取Git仓库
需要一个Git来管理源代码,本地也需要有一个Git仓库
通常有两种获取 Git 项目仓库的方式:
- 方式一:初始化一个Git仓库,并且可以将当前项目的文件都添加到Git仓库中(目前很多的脚手架在创建项目时都会默认创建一个Git仓库)
- **方式二:从其它服务器 克隆(clone) 一个已存在的 Git 仓库(第一天到公司通常我们需要做这个操作) **
**01 - **初始化Git仓库
git init
- 该命令将创建一个名为 .git 的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的核心
- **但是,在这个时候,我们仅仅是做了一个初始化的操作,你的项目里的文件还没有被跟踪 **
**02 - **Git拉取远程仓库
git clone 地址
2. 文件的状态划分
需要对文件来划分不同的状态,以确定这个文件是否已经归于Git仓库的管理:
- 未跟踪:默认情况下,Git仓库下的文件没有添加到Git仓库管理中,需要通过add命令来操作
- 已跟踪:添加到Git仓库管理的文件处于已跟踪状态,Git可以对其进行各种跟踪管理
通过使用 ( git add . ) 命令,可以使得文件被git跟踪,文件状态变为暂缓区
ps : 但是此时的文件并没有和commit对象建立联系,git log查看不到更改的记录
已跟踪的文件又可以进行细分状态划分:
- staged:暂缓区中的文件状态
- Unmodified:commit命令,可以将staged中文件提交到Git仓库
- Modified:修改了某个文件后,会处于Modified状态
**不管是新增的文件、修改的文件,都需重新让 add && commit **
3. git status
git status => 检测文件的状态
git status -s || git status --short => 文件状态的简洁信息
4. git add
git add => 文件添加到暂存区
git add 文件 => 跟踪新文件,并将其加入到暂存区
git add . => 将所有文件加入到暂存区
5. git commit
git commit => 文件更新提交,将暂存区的文件提交,和commit对象联系在一起
git commit –m "提交信息" => 提交文件,并写上记录
git commit --no-verify -m "XXX" => 忽略提交限制,一般eslint有
git commit -a -m "haha" => 相当于 git add. -> git commit -m 'haha' 的简写
6. git merge
git merge => 合并两分支代码 => git merge xxx分支名称
git merge dev --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并,可加 )
7. git log
git log => 查看一下所有的历史提交记录
git log => 详细记录
git log --oneline => 好看一点的记录
git log --pretty=oneline => 更好看一点的记录
git log --pretty=oneline --graph => 可以看到多分支的记录
**ps : 空格继续看记录,q是退出键 **
8. git reflog
git reflog => 不仅可以查看历史提交记录,而且切换版本的记录也会留下来
9. git reset
git reset => 版本回退
Git通过HEAD指针记录当前版本 :
- HEAD 是当前分支引用的指针,它总是指向该分支上的最后一次提交
- **理解 HEAD 的最简方式,就是将它看做 该分支上的最后一次提交 的快照 **
- 切换版本就是在改HEAD的指向
可以通过HEAD来改变Git目前的版本指向( 切换版本 )
- 上一个版本就是HEAD^,上上一个版本就是HEAD^^ => git reset --hard HEAD^
- 如果是上1000个版本,可以使用HEAD
1000 => git reset --hard HEAD1000 - 指定版本切换 通过git log 的 commit id => git reset --hard 2d44982
10. Git 的忽略文件 GitHub - github/gitignore
新建.gitignore文件 => 有些文件无需纳入Git 的管理,不需增加到缓存区
- 包括一些不需要提交的文件、文件夹
- 包括本地环境变量文件
- 包括一些日志文件
- 包括一些编辑器自动生成的文件
例如 vue 项目的.gitignore文件
11. git 底层原理
在进行提交操作时,Git 会保存一个提交对象(commit object)
- 该提交对象会包含一个指向暂存内容快照的指针
- 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针
- 首次提交产生的提交对象没有父对象,普通提交操作产生的提交对象有一个父对象
- 而由多个分支合并产生的提交对象有多个父对象
四、Git 远程仓库和本地仓库建立联系
1. 概念
项目通常是多人开发的,所以会将本地仓库中管理的代码共享到远程仓库中
- 远程仓库通常是搭建在某一个服务器上的(当然本地也可以,但是本地很难共享)
- 使用第三方的Git服务器:比如GitHub、Gitee、Gitlab等等
- **在自己服务器搭建一个Git服务 ( 可以使用Gitlab软件搭建一个git服务器 ) **
常见的远程仓库 :
- GitHub : GitHub: Where the world builds software · GitHub
- Gitee : Gitee - 基于 Git 的代码托管和研发协作平台
- 自己搭建Gitlab
不管是用哪个仓库,验证的方式都基本一样,这里使用gitee为例
2. 本地无仓库,远程有仓库
**对于私有的仓库需要进行验证 **
ps : 如果git bash中拉取不下来,记得在cmd环境中再试试
**目前Git服务器验证手段主要有两种 : **
- 方式一:基于HTTP的凭证存储(Credential Storage)
- **方式二:基于SSH的密钥 **
**01 - **远程仓库的验证 – 凭证
拉取代码
**拉取 : 测试仓库 => git clone 地址 **
ps : 一旦拉取仓库下来成功,就已经和远程仓库建立起了连接,可直接进行git操作
输入账号密码
提交代码
** git add . => git commit -m 'change' => git push **
删除凭证
windows
mac
**在系统用户的钥匙串中(加密的),删除即可 **
**02 - **远程仓库的验证 – SSH密钥
Secure Shell(安全外壳协议,简称SSH)是一种加密的网络传输协议,可在不安全的网络中为网络服务提供安全的传输环境。
SSH以非对称加密实现身份验证
- 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接,随后使用密码认证进行登录
- 另一种方法是人工生成一对公钥和私钥,通过生成的密钥进行认证,这样就可以在不输入密码的情况下登录- 公钥需要放在待访问的电脑之中,而对应的私钥需要由用户自行保管
0. 步骤
1. 用户在命令行输入命令,会生成公钥和私钥
2. 把公钥放在远程仓库中
one 生成公钥和私钥 生成/添加SSH公钥 - Gitee.com
ssh-keygen -t ed25519 -C “your email"
two 拿到公钥
** .pub文件中的内容就是公钥,复制下来即可**
three 把公钥放置在服务器中
fore拉取代码
git clone 地址
ps : 一旦拉取仓库下来成功,就已经和远程仓库建立起了连接,可直接进行git操作
3. 本地有仓库,和远程仓库建立连接
ps : 如果git bash中拉取不下来,记得在cmd环境中再试试
01 - 添加远程地址
添加远程地址:添加远程服务器(让本地的仓库和远程服务器仓库建立连接)
git remote add 远程仓库别名( 默认是origin ) 远程仓库地址
地址为HTTPS
验证方式则为 用户名 + 密码 > git remote add origin https://gitt.com
地址为SSH
验证方式则需配公钥和私钥 > git remote add origin git@gitter.git
ps : 一个本地仓库可以和多个远程仓库建立连接
02 - 建立连接 ( 重要 )
origin => 远程仓库名称,一个本地仓库可以和多个远程仓库连接,所以要指定是哪个
**ps : **
建议 远程仓库分支名字 和 本地仓库分支名 保持一样
否则拉取和推送时,可能需要多敲些许命令
**0. 前提是拥有本地仓库 **
** git init => git add . => git commit -m 'message'**
1. 添加远程仓库地址
git remote add origin git@gitee.com666.git
2. 触发输入账号密码 || 验证密钥,并拉取远程分支到本地
git pull
** **** 本地有分支,远程有分支**
3. 分支关联,建立跟踪分支 ( 上游分支 ) =>
=> git branch --set-upstream-to=远程仓库名字/远程分支的名字 本地分支的名字
git branch --set-upstream-to=origin/master master
4. 把远程仓库代码和本地代码合并 => git pull 远程仓库名字 远程仓库分支
git pull origin master --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并 )
5. 把代码推送到远程仓库中 --- 如果本地分支和远程分支名称不一样
git push **** **** ---- git push 远程仓库名字 远程仓库分支
本地有分支,远程没分支
3. 推送本地分支到远程,并建立远程跟踪分支 =>
=> git push --set-upstream 远程仓库名字 远程分支
**git push --set-upstream origin dev || git push -u **origin dev ( 简写 )
4. 若想要和远程的其他分支代码合并 => git merge 远程仓库名字/远程仓库分支** **
git merge origin/master --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并,如果有关系可以不写 )
03 - 查看远程仓库地址
查看远程地址:比如上面从GitHub上clone下来的代码,它就是有自己的远程仓库的
git remote => 简洁信息
git remote –v => 详细信息
04 - 重命名远程仓库别名
git remote rename 原仓库名 新仓库名
git remote rename origin gitlab
**05 - **移除远程地址
git remote remove 仓库名
git remote remove gitlab
五、Git 操作远程仓库
1. git clone
git clone 地址 => 把远程仓库克隆到本地
2. git push
git push => 将本地仓库的代码推送到远程仓库中
git push
git push -u 远程仓库名字 远程仓库分支
git push -u origin dev
3. git fetch
git fetch => 从远程仓库获取最新的代码
git fetch
git fetch 远程仓库名字 远程仓库分支
git fetch origin dev
4. git merge
**git merge => 合并两分支代码 **
**git merge **
git merge 远程仓库名字 远程仓库分支 允许两毫不相干的分支合并 ( 看情况加 )
git merge origin dev --allow-unrelated-histories
5. git pull
git pull => 从远程仓库pull代码,拉取远程代码到本地,并且合并
git pull => 相当于 git fetch + git merge
git pull 远程仓库名字 远程分支 允许两毫不相干的分支合并 ( 看情况加 )
git pull origin master --allow-unrelated-histories
六、git tag
对于重大的版本我们常常会打上一个标签,以表示它的重要性
- Git 可以给仓库历史中的某一个提交打上标签- 提交之后再打标签
- 比较有代表性的是人们会使用这个功能来标记发布结点( v1.0 、 v2.0 等等)
1. 创建标签
01 - 轻量标签
**创建tag标签 : git tag 标签名 (xxx版本号) **
git tag v1.0.0
02 - 附注标签
创建附注标签:通过-a选项,并且通过-m添加额外信息 => git tag -a 版本号 -m 信息
git tag -a v1.1.0 -m 'message,我干了什么'
2. 查看标签
基本查看 : 只能看到打的版本信息
git tag
详细查看 : 可以看到附注标签写的内容以及更改的代码内容 => git show 版本号
git show v1.1.0
3. 把打的标签推送到远程仓库中
默认情况下,git push 命令 并不会 传送标签到远程仓库服务器上
**推送指定tag到远程仓库中 => git push 远程仓库名 xxx版本号 **
git push origin v1.0.0
**推送全部tag到远程仓库中 => git push **远程仓库名 --tags
git push origin --tags
4. 删除本地tag
删除本地tag => git tag -d 版本号
git tag -d v1.0.0
5. 删除远程tag
删除远程tag => git push 远程仓库名 --delete 版本号
git push origin -d v1.0.0
6. 检出tag,回退到打tag的版本
回退到打tag的地方 => git checkout 版本号
git checkout v1.1.0
回退回来后,不要直接修改,若要修改,创建个新分支即可
git checkout -b '新分支名'
七、git 分支
Git 的分支,其实本质上仅仅是指向提交对象的可变指针
- Git 的默认分支名字是 master,在多次提交操作之后,其实已经有一个指向最后那个提交对象的 master 分支
- master 分支会在每次提交时自动移动
master分支
- Git 的 master 分支并不是一个特殊分支
- 它就跟其它分支完全没有区别
- 之所以几乎每一个仓库都有 master 分支,是因为 git init 命令默认创建它,并且大多数人都懒得去改动它
**1. 创建分支 **
Git 是怎么创建新分支的本质 => 只是创建了一个可以移动的新的指针
创建分支 => git branch xxx分支名
git branch testing
2. 查看分支
查看当前所有的分支
git branch
同时查看最后一次提交
git branch –v
查看所有合并到当前分支的分支
git branch --merged
查看所有没有合并到当前分支的分支
git branch --no-merged
3. 切换分支
切换分支 => git checkout xxx分支名
git checkout testing
4. 分支所在HEAD
Git 通过一个名为 HEAD 的特殊指针 知道当前在哪一个分支上
5. 创建分支并同时切换
创建分支并同时切换 => git checkout -b 'xxx分支名'
git checkout -b testing
推送到远程仓库中 => git push -u 远程仓库名 远程分支
git push -u origin testing
或者
**git push origin testing + git branch --set-upstream-to=origin/testing testing **
6. 在分支上提交图解
01 - 初始状态在master上提交
02 - 创建新分支testing,并在新分支上继续提交
03 - 切换回master分支上,并继续提交
04 - 在master分支上创建新分支dev,并继续提交
7. 分支的开发与合并
01 - 遇到线上bug
02 - 解决完后合并hotfix分支
8. 删除分支
**删除远程分支 **
git push -d origin 分支名
删除本地分支
git branch -D 分支名
9. 修改分支名称
修改本地分支名称
git branch -m 原分支名 新分支名
修改远程分支名称
**1.删除远程分支 **
** git push --delete origin 分支名**
2.修改本地分支名称
** git branch -m 原分支名 新分支名**
3.推送到远程仓库中
** git push -u origin 分支名**
10. git merge
git merge => 合并两分支代码 => git merge xxx分支名称 || git merge 远程仓库/远程分支
git merge dev --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并,可加 )
11. git cherry-pick
需求 : A分支要合并B分支提交的commit
git cherry-pick commit-Id
1. 进入B分支
** git log 查看提交记录,并记下commit-id**
2. 切换到A分支
** **git checkout A
3. 合并记录
** **git cherry-pick commit-id
4. 推送到远程仓库
** **** git push**
12. git reset
需求 : 回退版本
1.本地回退
git reset --hard HEAD^ 回退上一个版本
git reset --hard commitid ( git log 查看 ) 回退指定版本
2. 覆盖远程
git push -f
八、git rebase
在 Git 中整合来自不同分支的修改主要有两种方法:merge 以及 rebase
1. 使用了merge
在master上直接使用merge
git merge experiment
2. 使用了rebase
在experiment上直接使用rebase
git rebase master
再次执行master上的合并操作
git checkout master
git merge experiment
3. 原理
**rebase是如何工作的 : **
- 它的原理是首先找到这两个分支(即当前分支 experiment、变基操作的目标基底分支 master) 的最近共同祖先 C2
- 然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件
- 然后将当前分支指向目标基底 C3
- 最后以此将之前另存为临时文件的修改依序应用
4. rebase和merge的选择
rebase和merge是对Git历史的不同处理方法:
- merge : 用于记录git的所有历史,那么分支的历史错综复杂,也全部记录下来
- rebase : 用于简化历史记录,将两个分支的历史简化,整个历史更加简洁
rebase有一条黄金法则:永远不要在主分支上使用rebase
- 如果在主分支上面使用rebase,会造成大量的提交历史在main分支中不同
- **而多人开发时,其他人依然在原来的main中,对于提交历史来说会有很大的变化 **
九、总结操作
远程仓库有项目 ( 公司 )
**0. git服务器验证,看上面文章内容 **
1. 克隆项目到本地
git clone xxxxxxxx地址
2. 一般在master分支上创建自己的分支或者功能分支 dev-star
git checkout -b dev-star
3. 把创建好的分支推送到远程仓库,建立跟踪分支 dev-star
git push -u origin dev-star
4. 编写代码
阿巴阿巴阿巴阿巴阿巴
5. 把本地代码添加到暂存区
git add .
6. 把暂存区代码和commit对象关联,生成提交记录
git commit -m 'feat: messsage'
7. 从远程拉取最新代码到本地
git pull
8. 推送本地代码到远程仓库
git push
9. 合并代码到master分支上
** 01 - 切换回主分支**
** ****git checkout master **
** 02 - 合并最新的master代码**
** git pull**
** **03 - 自己的分支或者功能分支
**git merge ****dev-star **
** 04 - 解决可能存在的冲突,提交合并的代码**
** git commit -a -m ' ' => git push**
十、Git常见命令速查表
版权归原作者 玄鱼殇 所有, 如有侵权,请联系我们删除。