Git版本控制工具(详解)

Git版本控制工具

Git常见命令速查表

在这里插入图片描述

集中式版本控制

cvs和svn都是属于集中式版本控制系统

  • 他们的主要特点是单一的集中管理服务器 保存所有文件的修订版本
  • 协同开发人员通过客户端连接到这台服务器 取出最新的文件或者提交更新
    优点
  • 每个人都可以在一定程度上看到项目中的其他人在做些什么
    缺点
  • 中央服务器不能出现故障 一旦出现故障 谁都无法提交更新 如果此时中心数据库所在的磁盘发生破坏 又没做好恰当的备份 就会失去所有数据

分布式版本控制

git是属于分布式版本控制系统

  • 客户端不只是提取最新版本的文件快照 而是把代码仓库完整的镜像下来 包括完整的历史记录
  • 任何一处协同工作用的服务器发生故障 事后都可以用任何一个镜像出来的本地仓库恢复
  • 因为每次一克隆操作 实际上都是一次对代码仓库的完整备份

Bash - CMD - GUI区别

Bash,Unix shell 的一种,Linux 与 Mac OS X 都将它作为默认 shell。

  • Git Bash 就是一个 shell,是 Windows 下的命令行工具,可以执行 Linux 命令
  • Git Bash 是基于 CMD 的,在 CMD 的基础上增添一些新的命令与功能
  • 所以建议在使用的时候,用 Bash 更加方便

Git CMD

  • 命令行提示符(CMD)是 Windows 操作系统上的命令行解释程序
  • 当你在 Windows 上安装 git 并且习惯使用命令行时,可以使用 cmd 来运行 git 命令;

Git GUI

  • 基本上针对那些不喜欢黑屏(即命令行)编码的人;
  • 它提供了一个图形用户界面来运行 git 命令;

获取Git仓库 – git init/git clone

我们需要一个Git来管理源代码,那么我们本地也需要有一个Git仓库。
通常有两种获取 Git 项目仓库的方式:

  • 方式一:初始化一个Git仓库,并且可以将当前项目的文件都添加到Git仓库中(目前很多的脚手架在创建项目时都会默认创建一个Git仓库);
  • 方式二:从其它服务器 克隆(clone) 一个已存在的 Git 仓库(第一天到公司通常我们需要做这个操作);
    方式一:初始化Git仓库
  • 该命令将创建一个名为 .git 的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的核心;
  • 但是,在这个时候,我们仅仅是做了一个初始化的操作,你的项目里的文件还没有被跟踪;
    git init
    方式二:从Git远程仓库
    git clone …

文件的状态划分

现在我们的电脑上已经有一个Git仓库:

  • 在实际开发中,你需要将某些文件交由这个Git仓库来管理;
  • 并且我们之后会修改文件的内容,当达成某一个目标时,想要记录下来这次操作,就会将它提交到仓库中;
    那么我们需要对文件来划分不同的状态,以确定这个文件是否已经归于Git仓库的管理:
  • 未跟踪:默认情况下,Git仓库下的文件也没有添加到Git仓库管理中,我们需要通过add命令来操作;
  • 已跟踪:添加到Git仓库管理的文件处于已跟踪状态,Git可以对其进行各种跟踪管理;
    已跟踪的文件又可以进行细分状态划分:
  • staged:暂缓区中的文件状态;
  • Unmodified:commit命令,可以将staged中文件提交到Git仓库
  • Modified:修改了某个文件后,会处于Modified状态;
    在工作时,你可以选择性地将这些修改过的文件放入暂存区;
    然后提交所有已暂存的修改,如此反复;

git操作流程图

在这里插入图片描述

检测文件的状态 - git status

我们在有Git仓库的目录下新建一个文件,查看文件的状态:
git status
Untracked files:未跟踪的文件

  • 未跟踪的文件意味着 Git 在之前的提交中没有这些文件;
  • Git 不会自动将之纳入跟踪范围,除非你明明白白地告诉它“我需要跟踪该文件”;
    我们也可以查看更加简洁的状态信息:
    git status –s
    git status --short

文件添加到暂存区 – git add

跟踪新文件命令
git add aaa.js
使用命令git add 开始跟踪一个文件

跟踪修改的文件命令

  • 如果我们已经跟踪了某一个文件 这个时候修改了文件也需要重新添加到暂存区中

通过git add . 将多有文件添加到暂存区中、

git忽略文件

一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在
未跟踪文件列表。

  • 通常都是些自动生成的文件,比如日志文件,或者编译过程中创建
    的临时文件等;
  • 我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件的模
    式;
    在实际开发中,这个文件通常不需要手动创建,在必须的时候添加自
    己的忽略内容即可;
    比如创建的Vue项目自动创建的忽略文件:
  • 包括一些不需要提交的文件、文件夹;
  • 包括本地环境变量文件;
  • 包括一些日志文件;
  • 包括一些编辑器自动生成的文件;

文件更新提交 – git commit

现在的暂存区已经准备就绪,可以提交了。

  • 每次准备提交前,先用 git status 看下,你所需要的文件是不是都已暂存起来了;
  • 再运行提交命令 git commit;
  • 可以在 commit 命令后添加 -m 选项,将提交信息与命令放在同一行;
    git commit –m “提交信息”
    如果我们修改文件的add操作,加上commit的操作有点繁琐,那么可以将两个命令结合来使用:
    git commit -a -m “修改了bbb文件”

Git的校验和

git中所有的数据在存储前都计算校验和 然后以校验和来引用

  • Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希);
  • 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容或目录结构计算出来;

查看提交的历史-git log

在提交了若干更新,又或者克隆了某个项目之后,有时候我们想要查看一下所有的历史提交记录。
这个时候我们可以使用git log命令:

  • 不传入任何参数的默认情况下,git log 会按时间先后顺序列出所有的提交,最近的更新排在最上面;
  • 这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明;
    git log
    git log --pretty=oneline
    git log --pretty=oneline --graph

版本回退 – git reset

如果想要进行版本回退 我们需要先知道目前处于哪一个版本 Git通过HEAD指针记录当前版本

  • HEAD 是当前分支引用的指针,它总是指向该分支上的最后一次提交;
  • 理解 HEAD 的最简方式,就是将它看做 该分支上的最后一次提交 的快照;
    在这里插入图片描述

我们可以通过HEAD来改变git目前的版本指向

  • 上一个版本就是HEAD^ 上上个版本就是HEAD^^
  • 如果是上1000个版本 我们可以使用HEAD~1000
  • 我们可以可以指定某一个commit id;

git reset --hard HEAD^
git reset --hard HEAD~1000
git reset --hard 2d44982

远程仓库的验证

目前git服务器验证手段主要有两种
方式一: 基于HTTP的凭证存储
方式二: 基于SSH的密钥

远程仓库的验证-SSH密钥

SSH是一种加密的网络传输协议 可在不安全的网络中为网络服务提供安全的传输环境
SSH以非对称加密实现身份验证

  • 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接,随后使用密码认证进行登录;
  • 另一种方法是人工生成一对公钥和私钥,通过生成的密钥进行认证,这样就可以在不输入密码的情况下登录;
  • 公钥需要放在待访问的电脑之中,而对应的私钥需要由用户自行保管;

管理远程服务器

查看远程地址:比如我们之前从GitHub上clone下来的代码,它就是有自己的远程仓库的
git remote
git remote -v
-v是-verbose的缩写(冗长的)
添加远程地址:我们也可以继续添加远程服务器(让本地的仓库和远程服务器仓库建立连接):
git remote add < shortname > < url >
重命名远程地址 git remote rename gitlab glab
移除远程地址 git remote remove gitlab

本地分支的上游分支(跟踪分支)

问题一:当前分支没有track的分支
在这里插入图片描述
原因:当前分支没有和远程的origin/master分支进行跟踪

  • 在没有跟踪的情况下,我们直接执行pull操作的时候必须指定从哪一个远程仓库中的哪一个分支中获取内容
    在这里插入图片描述
    如果我们想要直接执行git fetch是有一个前提的:必须给当前分支设置一个跟踪分支:
    在这里插入图片描述
    在这里插入图片描述

拒绝合并不相干的历史

问题二:合并远程分支时,拒绝合并不相干的历史
在这里插入图片描述
简单来说就是:过去git merge允许将两个没有共同基础的分支进行合并,这导致了一个后果:新创建的项目可能被一个毫不
怀疑的维护者合并了很多没有必要的历史,到一个已经存在的项目中,目前这个命令已经被纠正,但是我们依然可以通过–
allow-unrelated-histories选项来逃逸这个限制,来合并两个独立的项目;

在这里插入图片描述

远程仓库的交互

从远程仓库clone代码:将存储库克隆到新创建的目录中;
git clone
将代码push到远程仓库:将本地仓库的代码推送到远程仓库中;

  • 默认情况下是将当前分支(比如master)push到origin远程仓库的;

git push
git push origin master
从远程仓库fetch代码:从远程仓库获取最新的代码

  • 默认情况下是从origin中获取代码;

git fetch
git fetch origin

  • 获取到代码后默认并没有合并到本地仓库,我们需要通过merge来合并;
    git merge
    从远程仓库pull代码:上面的两次操作有点繁琐,我们可以通过一个命令来操作
    git pull
    git fetch + gir merge(rebase)

常见的开源协议

在这里插入图片描述

Git标签(tag) - 删除和检出tag

删除本地tag
要删除掉你本地仓库上的标签,可以使用命令 git tag -d < tagname >
git tag -d v1.1
删除远程tag
要删除远程的tag我们可以通过git push < remote > –-delete < tagname >
git push origin --delete v1.1
检出tag

  • 如果你想查看某个标签所指向的文件版本,可以使用 git checkout 命令
  • 通常我们在检出tag的时候还会创建一个对应的分支

git checkout v1.0

Git提交对象(Commit Object)

几乎所有的版本控制系统都以某种形式支持分支。

  • 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线。
    在进行提交操作时,Git 会保存一个提交对象(commit object):
  • 该提交对象会包含一个指向暂存内容快照的指针;
  • 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针;
    • 首次提交产生的提交对象没有父对象,普通提交操作产生的提交对象有一个父对象;
    • 而由多个分支合并产生的提交对象有多个父对象;

Git master分支

Git 的分支,其实本质上仅仅是指向提交对象的可变指针。

  • Git 的默认分支名字是 master,在多次提交操作之后,你其实已经有一个指向最后那个提交对象的 master 分支;
  • master 分支会在每次提交时自动移动;
    Git 的 master 分支并不是一个特殊分支。
  • 它就跟其它分支完全没有区别;
  • 之所以几乎每一个仓库都有 master 分支,是因为 git init 命令默认创建它,并且大多数人都懒得去改动它;

在这里插入图片描述

Git创建分支

Git 是怎么创建新分支的呢?

  • 很简单,它只是为你创建了一个可以移动的新的指针;
    比如,创建一个 testing 分支, 你需要使用 git branch 命令:
    git branch testing
    那么,Git 又是怎么知道当前在哪一个分支上呢?
  • 也很简单,它也是通过一个名为 HEAD 的特殊指针;
    git checkout testing

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

Git分支提交

如果我们指向某一个分支,并且在这个分支上提交:
在这里插入图片描述
你也可以切换回到master分支,继续开发:
在这里插入图片描述
在这里插入图片描述

创建分支同时切换

创建新分支的同时切换过去

  • 通常我们会在创建一个新分支后立即切换过去;
  • 这可以用 git checkout -b < newbranchname > 一条命令搞定;

为什么需要使用分支呢?

让我们来看一个简单的分支新建与分支合并的例子,实际工作中你可能会用到类似的工作流。

  • 开发某个项目,在默认分支master上进行开发;
  • 实现项目的功能需求,不断提交;
  • 并且在一个大的版本完成时,发布版本,打上一个tag v1.0.0;
    继续开发后续的新功能,正在此时,你突然接到一个电话说有个很严重的问题需要紧急修补, 你将按照如下方式来处理:
  • 切换到tag v1.0.0的版本,并且创建一个分支hotfix;
    想要新建一个分支并同时切换到那个分支上,你可以运行一个带有 -b 参数的 git checkout 命令:
    git checkout -b hotfix
    在这里插入图片描述
    在这里插入图片描述

分支开发和合并

分支上开发、修复bug:

  • 我们可以在创建的hotfix分支上继续开发工作或者修复bug;
  • 当完成要做的工作后,重新打上一个新的tag v1.0.1;
    切换回master分支,但是这个时候master分支也需要修复刚刚的bug:
  • 所以我们需要将master分支和hotfix分支进行合并;

git checkout master
git merge hotfix
在这里插入图片描述
在这里插入图片描述

查看和删除分支

如果我们希望查看当前所有的分支,可以通过以下命令:
git branch 查看当前所有的分支
git branch –v 同时查看最后一次提交
git branch --merged 查看所有合并到当前分支的分支
git branch --no-merged 查看所有没有合并到当前分支的分支
在这里插入图片描述

如果某些已经合并的分支我们不再需要了,那么可以将其移除掉:
git branch –d hotfix 删除当前分支
git branch –D hotfix 强制删除某一个分支

Git的工作流(git flow)

由于Git上分支的使用的便捷性,产生了很多Git的工作流:

  • 也就是说,在整个项目开发周期的不同阶段,你可以同时拥有多个开放的分支;
  • 你可以定期地把某些主题分支合并入其他分支中;
    比如以下的工作流:
  • master作为主分支;
  • develop作为开发分支,并且有稳定版本时,合并到master分支中;
  • topic作为某一个主题或者功能或者特性的分支进行开发,开发完成后合并到develop分支中;
    在这里插入图片描述

比较常见的git flow

在这里插入图片描述

Git的远程分支

远程分支是也是一种分支结构:

  • 以 < remote >/< branch > 的形式命名的;
    如果我们刚刚clone下来代码,分支的结构如下:
    如果其他人修改了代码,那么远程分支结构如下:
  • 你需要通过fetch来获取最新的远程分支提交信息

在这里插入图片描述

远程分支的管理

操作一:推送分支到远程

  • 当你想要公开分享一个分支时,需要将其推送到有写入权限的远程仓库上;
  • 运行 git push < remote > < branch >;

git push origin < branch >

操作二:跟踪远程分支

  • 当克隆一个仓库时,它通常会自动地创建一个跟踪 origin/master 的 master 分支;
  • 如果你愿意的话可以设置其他的跟踪分支,可以通过运行 git checkout --track < remote >/< branch >
  • 如果你尝试检出的分支 (a) 不存在且 (b) 刚好只有一个名字与之匹配的远程分支,那么 Git 就会为你创建一个跟踪分支;
    git checkout --track < remote >/< branch >

操作三:删除远程分支

  • 如果某一个远程分支不再使用,我们想要删除掉,可以运行带有 --delete 选项的 git push 命令来删除一个远程分支。

git push origin --delete < branch >

Git rebase用法

在 Git 中整合来自不同分支的修改主要有两种方法:merge 以及 rebase。
在这里插入图片描述
在这里插入图片描述

什么是rebase呢?

  • 在上面的图例中,你可以提取在 C4 中引入的补丁和修改,然后在 C3 的基础上应用一次;
  • 在 Git 中,这种操作就叫做 变基(rebase);
  • 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上,就好像“重新播放”一样;
  • rebase这个单词如何理解呢?
    • 我们可以将其理解成改变当前分支的base;
    • 比如在分支experiment上执行rebase master,那么可以改变experiment的base为master
    • git checkout experiment
    • git rebase master

rebase的原理

rebase是如何工作的呢?

  • 它的原理是首先找到这两个分支(即当前分支 experiment、变基操作的目标基底分支 master) 的最近共同祖先 C2;
  • 然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件;
  • 然后将当前分支指向目标基底 C3;
  • 最后以此将之前另存为临时文件的修改依序应用;

我们可以再次执行master上的合并操作:
git checkout master
git merge experiment

rebase和merge的选择

开发中对于rebase和merge应该如何选择呢?
事实上,rebase和merge是对Git历史的不同处理方法:

  • merge用于记录git的所有历史,那么分支的历史错综复杂,也全部记录下来;
  • rebase用于简化历史记录,将两个分支的历史简化,整个历史更加简洁;
    了解了rebase的底层原理,就可以根据自己的特定场景选择merge或者rebase。
    注意:rebase有一条黄金法则:永远不要在主分支上使用rebase
  • 如果在main上面使用rebase,会造成大量的提交历史在main分支中不同
  • 而多人开发时,其他人依然在原来的main中,对于提交历史来说会有很大的变化;
  • 在这里插入图片描述
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

_聪明勇敢有力气

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值