文章目录

1. 初识 Git

提出问题

不知道你工作或学习时，有没有遇到这样的情况：我们在编写各种文档时，为了防止文档丢失，更改失误，失误后能恢复到原来的版本，不得不复制出一个副本，比如：

“报告-v1”
“报告-v2”
“报告-v3”
“报告-确定版”
“报告-最终版”
“报告-究极进化版”
......

每个版本有各自的内容，但最终会只有一份报告需要被我们使用。

但在此之前的工作都需要这些不同版本的报告，于是每次都是复制粘贴副本，产出的文件就越来越多，文件多不是问题，问题是：随着版本数量的不断增多，你还记得这些版本各自都是修改了什么吗？

文档如此，我们写的项目代码，也是存在这个问题的！！如何解决呢？

版本控制器

为了能够更方便我们管理这些不同版本的文件，便有了 版本控制器。所谓的版本控制器，就是能让你了解到一个文件的历史，以及它的发展过程的系统。通俗的讲就是一个可以记录工程的每一次改动和版本迭代的一个管理系统，同时也方便多人协同作业。

目前最主流的版本控制器就是 Git。Git 可以控制电脑上所有格式的文件，例如 doc、excel、dwg、dgn、rvt 等等。对于我们开发人员来说，Git 最重要的就是可以帮助我们管理软件开发项目中的源代码文件！

在这里插入图片描述

注意事项

还需要再明确一点，所有的版本控制系统，Git 也不例外，其实只能跟踪文本文件的改动，比如 TXT 文件，网页，所有的程序代码等等。版本控制系统可以告诉你每次的改动，比如在第 5 行加了一个单词 Linux，在第 8 行删了一个单词 Windows。

而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从 100KB 改成了 120KB，但到底改了啥，版本控制系统不知道，也没法知道。

2. 安装 Git

我用 Linux 系统是 Centos7.9，安装方式非常简单。

首先，执行安装命令：

sudo yum install -y git

查看 Git 安装的版本：

git --version

如下图所示（安装成功）

在这里插入图片描述

如果你的 Linux 是 Ubuntu 系统，那么安装命令如下：

sudo apt-get install git -y

安装完成之后，还可以进行几个小小的设置：

# 打开 Git 颜色
git config --global color.ui auto

3. 创建 Git 本地仓库

首先，仓库是进行版本控制的一个文件目录。我们要想对文件进行版本控制，就必须先创建一个仓库出来。

创建一个 Git 本地仓库对应的命令为 git init，注意命令要在文件目录下执行，例如：

# 在家目录下创建一个文件夹（用于测试）
mkdir gitCode

# 初始化命令
cd gitCode/
git init

我们发现，当前目录下多了一个 .git 的隐藏文件，.git 目录是 Git 来跟踪管理仓库的，不要手动修改这个目录里面的文件，不然改乱了，就把 Git 仓库给破坏了。

其中包含 Git 仓库的诸多细节，如下所示：

在这里插入图片描述

4. 配置 Git 本地仓库

当安装 Git 后首先要做的事情是设置你的 用户名称 和 e-mail 地址，这是非常重要的。

配置命令为：

git config [--global] user.name "Your Name"   
git config [--global] user.email "email@example.com" 

# 把 Your Name 改成你的昵称
# 把 email@example.com 改成邮箱的格式，只要格式正确即可。

其中 --global 是一个可选项。如果使用了该选项，表示这台机器上所有的 Git 仓库都会使用这个配置。如果你希望在不同仓库中使用不同的 name 或 e-mail，可以不要 --global 选项，但要注意的是，执行命令时必须要在仓库里。

查看配置命令为：

git config -l

如下图所示：

在这里插入图片描述

删除对应的配置命令为：

git config [--global] --unset user.name
git config [--global] --unset user.email

5. 认识工作区、暂存区、版本库

  • 工作区：是在电脑上你要写代码或文件的目录。
  • 暂存区：英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，我们把暂存区有时也叫作索引（index）。
  • 版本库：又名仓库，英文名 repository。工作区有一个隐藏目录 .git，它不算工作区，而是 Git 的版本库。这个版本库里面的所有文件都可以被 Git 管理起来，每个文件的修改、删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以 “还原”。

下面这个图展示了工作区、暂存区和版本库之间的关系：

在这里插入图片描述

  • 图中左侧为工作区，右侧为版本库。Git 的版本库里存了很多东西，其中最重要的就是暂存区。
  • 在创建 Git 版本库时，Git 会为我们自动创建一个唯一的 master 分支，以及指向 master 的一个指针叫 HEAD。
  • 当对工作区修改（或新增）的文件执行 git add 命令时，暂存区目录树的文件索引会被更新。
  • 当执行提交操作 git commit 时，master 分支会做相应的更新，可以简单理解为暂存区的目录树才会被真正写到版本库中。

由上述描述我们便能得知：通过新建或粘贴进目录的文件，并不能称之为向仓库中新增文件，而只是在工作区新增了文件。必须要通过使用 git add 和 git commit 命令才能将文件添加到仓库中进行管理！！！

6. 添加文件（场景一）

在包含 .git 的目录下新建一个 ReadMe 文件，我们可以使用 git add 命令可以将文件添加到暂存区：

  • 添加一个或多个文件到暂存区：git add [file1] [file2] ...
  • 添加指定目录到暂存区，包括子目录：git add [dir]
  • 添加当前目录下的所有文件改动到暂存区：git add .

再使用 git commit 命令将暂存区内容添加到本地仓库中：

  • 提交暂存区全部内容到本地仓库中：git commit -m "message"
  • 提交暂存区的指定文件到仓库区：git commit [file1] [file2] ... -m "message"

注意 git commit 后面的 -m 选项，要跟上描述本次提交的 message，由用户自己完成，这部分内容绝对不能省略，并要好好描述，是用来记录你的提交细节，是给我们人看的。

来看一个小小的示例：

# 创建文件
touch ReadMe

# 往文件中写入一些信息
echo "hello world" > ReadMe

# 添加文件到暂存区
git add ReadMe

# 提交暂存区全部内容到本地仓库中
git commit -m "add first file"

如下图所示：

在这里插入图片描述

git commit 命令执行成功后会告诉我们，1 个文件被改动（就是我们新添加的 ReadMe 文件），插入了一行内容（ReadMe有一行内容）。

我们还可以多次 add 不同的文件，而只 commit 一次便可以提交所有文件，是因为需要提交的文件全部被 add 到暂存区中，然后一次性 commit 暂存区的所有修改。

示例如下：

# 一次性创建三个文件
touch file1 file2 file3

# 添加文件到暂存区
git add file1
git add file2
git add file3

# 提交暂存区全部内容到本地仓库中
git commit -m "add 3 files"

结果如下：

在这里插入图片描述

截至目前为止，我们已经更够将代码直接提交至本地仓库了。我们可以使用 git log 命令，来查看下历史提交记录：

git log

结果如下：

在这里插入图片描述

该命令显示从最近到最远的提交日志，并且可以看到我们 commit 时的日志消息。

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline 参数：

git log --pretty=oneline

结果如下：

在这里插入图片描述

需要说明的是，我们看到的一大串类似 f87b8...1f15a 的是每次提交的 commit id（版本号），Git 的 commit id 不是1，2，3…… 递增的数字，而是一个 SHA1 计算出来的一个非常大的数字，用十六进制表示。

一般情况下可以添加一个 --decorate 选项，这样会自动显示 (HEAD -> master)

git log --pretty=oneline --decorate
git log --oneline --decorate

结果如下：

在这里插入图片描述

如果你觉得命令太长的话，可以使用 alias 来取个别名：

# 不显示全部的commit id
git config --global alias.lg "log --oneline --decorate" 

# 显示全部的commit id
git config --global alias.lg "log --pretty=oneline --decorate"

# 等同于
git lg

# 删除别名
git config --global --unset alias.lg

结果如下：

在这里插入图片描述

7. 查看 .git 文件

先来看看我们的 .git 的目录结构：

[Tom@vm-centos:~/gitCode]$ tree .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── 25
│   │   └── 1f5c5b7c0b8937ee454e3c1ec6a26e92951bd5
│   ├── 3b
│   │   └── 18e512dba79e4c8300dd08aeb37f8e728b8dad
│   ├── 82
│   │   └── a432cf4469d279b2ec65a226fbbb5c19fb56c9
│   ├── c7
│   │   └── 1a43753248618b175fa1bf578d696175e5d00f
│   ├── e6
│   │   └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│   ├── f8
│   │   └── 7b8416cc9b2e49d3a84fa3a7704b24cfb1f15a
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

18 directories, 24 files

其中 index 就是我们的暂存区，git add 之后的内容都是添加到这里的。

而 HEAD 就是我们的默认指向 master 分支的指针：

[Tom@vm-centos:~/gitCode]$ cat .git/HEAD 
ref: refs/heads/master

而默认的 master 分支，其实就是：

[Tom@vm-centos:~/gitCode]$ cat .git/refs/heads/master 
f87b8416cc9b2e49d3a84fa3a7704b24cfb1f15a

打印的 f87b8416...fb1f15a 是什么东西呢？其实保存的就是当前最新的 commit id。

而 objects 为 Git 的对象库，里面包含了创建的各种版本库对象及内容。当执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，就位于 git/objects 目录下，让我们来看看这些对象有何用处：

[Tom@vm-centos:~/gitCode]$ ls .git/objects/
25  3b  82  c7  e6  f8  info  pack

查找 object 时要将 commit id 分成 2 部分，其前 2 位是文件夹名称，后 38 位是文件名称。

找到这个文件之后，一般不能直接看到里面是什么，该类文件是经过 sha（安全哈希算法）加密过的文件，好在我们可以使用 git cat-file 命令来查看版本库对象的内容：

# 可以看到这就是我们最近⼀次的提交！
[Tom@vm-centos:~/gitCode]$ git cat-file -p f87b8416cc9b2e49d3a84fa3a7704b24cfb1f15a
tree 82a432cf4469d279b2ec65a226fbbb5c19fb56c9
parent c71a43753248618b175fa1bf578d696175e5d00f
author Tom <123456@gmail.com> 1767277039 +0800
committer Tom <123456@gmail.com> 1767277039 +0800

add 3 files

其中，还有一行 tree 82a432cf4469d279b2ec65a226fbbb5c19fb56c9，我们使用同样的方法，看看结果：

[Tom@vm-centos:~/gitCode]$ git cat-file -p 82a432cf4469d279b2ec65a226fbbb5c19fb56c9
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad	ReadMe
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file2
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file3

再看 ReadMe 对应的 3b18e512dba79e4c8300dd08aeb37f8e728b8dad：

# 可以看到，这是我们对ReadMe做的修改，被git记录了下来！！
[Tom@vm-centos:~/gitCode]$ git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
hello world

如下图所示：

在这里插入图片描述

总结一下，在本地的 git 仓库中，有几个文件或者目录很特殊：

  • index：暂存区，git add 后会更新该内容。
  • HEAD：默认指向 master 分支的一个指针。
  • refs/heads/master：文件里保存当前 master 分支的最新 commit id。
  • objects：包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改。

后面再学习过程中，最好能将常见的 git 操作与 .git 目录当中的结构内容变化对应起来，这样有利于我们理解 git 细节流程。

8. 添加文件（场景二）

学习到这里，我们已经清楚了如何向仓库中添加文件，并且对于工作区、暂存区、版本库也有了一定的认识。那么我们再展示一种添加文件的场景，能加深对工作区、暂存区、版本库的理解，示例如下：

# 新增file4文件
touch file4

# 将file4添加到暂存区
git add file4

# 新增file5文件
touch file5

# 提交修改
git commit -m "add file"

结果如下：

在这里插入图片描述

提交后发现打印了 1 file changed, 0 insertions(+), 0 deletions(-)，意思是只有一个文件改变了，这时我们提出了疑问，不是新增了两个文件吗？

再来回忆下，git add 是将文件添加到暂存区，git commit 是将暂存区的内容添加到本地仓库中。由于我们并没有使用 git add file5，file5 就不在暂存区中维护，所以我们 commit 的时候其实只是把已经在暂存区的 file4 提交了，而遗漏了工作区的 file5。

如何提交 file5 呢？很简单，再次 add, commit 即可。

# 将file5添加到暂存区
git add file5

# 提交修改
git commit -m "add file5"

结果如下：

在这里插入图片描述

9. 修改文件

Git 比其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，而非文件。

什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。

现在我们将ReadMe文件进行一次修改：

# 向文件中追加写入一行
echo "hello git" >> ReadMe

此时，仓库中的 ReadMe 和我们工作区的 ReadMe 是不同的，如何查看当前仓库的状态呢？git status 命令用于查看在你上次提交之后是否有对文件进行再次修改。

# 查看状态
git status

结果如下：

在这里插入图片描述

上面的结果告诉我们，ReadMe 被修改过了，但还没有完成添加与提交。

目前，我们只知道文件被修改了，如果能知道具体哪些地方被修改了，就更好了。（比如：你还记得你三天前写了什么代码吗？或者没写？）

# 查看修改的位置
git diff ReadMe

结果如下：

在这里插入图片描述

git diff [file] 命令用来显示暂存区和工作区文件的差异，显示的格式正是 Unix 通用的 diff 格式。（也可以使用 git diff HEAD -- [file] 命令来查看版本库和工作区文件的区别）

知道了对 ReadMe 做了什么修改后，再把它提交到本地仓库就放心多了。

# 将文件添加到暂存区
git add ReadMe

# 再次查看状态
git status

结果如下：

在这里插入图片描述

git add 之后，就没有看到上面 no changes added to commit (use "git add" and/or "git commit -a") 的消息了。接下来让我们继续 git commit 即可：

# 提交修改
git commit -m "modify ReadMe"

# 再次查看状态
git status

结果如下：

在这里插入图片描述

10. 版本回退

之前我们也提到过，Git 能够管理文件的历史版本，这也是版本控制器重要的能力。如果有一天你发现之前的工作出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

执行 git reset 命令用于回退版本，可以指定退回某一次提交的版本。要解释一下 回退 本质是要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定：

git reset 命令语法格式为：git reset [--soft | --mixed | --hard] [HEAD]

  • --mixed 为默认选项，使用时可以不用带该参数。该参数将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
  • --soft 参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
  • --hard 参数将暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个命令，因为工作区会回滚，你没有提交的代码就再也找不回了，所以使用该参数前一定要慎重。
  • HEAD 说明：
    • 可直接写成 commit id，表示指定退回的版本
    • HEAD 表示当前版本
    • HEAD^ 上一个版本
    • HEAD^^ 上上一个版本
    • 以此类推…
  • 可以使用 ~数字 表示：
    • HEAD~0 表示当前版本
    • HEAD~1 上一个版本
    • HEAD~2 上上一个版本
    • 以此类推…

我们目前 ReadMe 中有两行内容，分别是：

[Tom@vm-centos:~/gitCode]$ cat ReadMe 
hello world
hello git

那么如果要回退的话，上面的参数用法如下：

ReadMe 工作区 暂存区 版本库 本质是回退的版本库的内容（git reset 参数）
world world、git world、git world、git （初始状态）
world、git world、git world、git word --soft
world、git world world --mixed（默认选项）
world world world --hard（慎用！！！）

为了便于表述，方便测试回退功能，我们先做一些准备工作：更新 3 个版本的 ReadMe，并分别进行 3 次提交，如下所示。

# 第⼀次修改提交
echo "hello version1" >> ReadMe 
git add ReadMe
git commit -m "add version1"

# 第⼆次修改提交
echo "hello version2" >> ReadMe 
git add ReadMe
git commit -m "add version2"

# 第三次修改提交
echo "hello version3" >> ReadMe 
git add ReadMe
git commit -m "add version3"

# 查看历史提交记录
git lg

结果如下：

在这里插入图片描述

现在，如果我们提交完 version3 后，发现 version3 编写错误，想回退到 version2，重新基于 version2 开始编写。由于我们在这里希望的是将工作区的内容也回退到 version2 版本，所以需要用到 --hard 参数。

示例如下：

# 查看
git lg

# 回退
git reset --hard fceae2d477e89b24e946adaa92bc84a89209e492

我们惊奇的发现，此时ReadMe文件的内容，已经回退到 version2 了！当前，我们再次用 git log 查看一下提交日志，发现 HEAD 指向了 version2，如下所示：

在这里插入图片描述

到这里一般回退功能就演示完了，但现在如果我后悔了，想再回到 version3 怎么办？我们可以继续使用 git reset 命令，回退到 version3 版本，但我们必须要拿到 version3 的 commit id 去指定回退的版本。

但我们看到了 git log 并不能打印出 version3 的 commit id，运气好的话我们可以从终端上去找找之前的记录，运气不好的话 commit id 已经被我们搞丢了。

别担心，Git 还提供了一个 git reflog 命令能补救一下，该命令用来记录本地的每一次命令。

git reflog

结果如下：

在这里插入图片描述

这样，你就可以很方便的找到你的所有操作记录了，但 a1314be 这个是啥东西？这个是 version3 的 commit id 的部分。没错，Git 版本回退的时候，也可以使用部分 commit id 来代表目标版本。示例如下：

# 回退到v3
git reset --hard a1314be

# 查看⼯作区
cat ReadMe

# 查看log
git lg

结果如下：

在这里插入图片描述

可往往在实际开发中，由于长时间的开发了，导致 commit id 早就找不到了，可突然某一天，我又想回退到 version3，那该如何操作呢？貌似现在不可能了。。。

值得说的是，Git 的版本回退速度非常快，因为 Git 在内部有个指向当前分支（此处是 master）的 HEAD 指针，refs/heads/master 文件里保存当前 master 分支的最新 commit id。当我们在回退版本的时候，Git 仅仅是给 refs/heads/master 中存储一个特定的 version，可以简单理解成如下示意图：

在这里插入图片描述

11. 撤销修改

如果我们在我们的工作区写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到上一个版本。

具体情况如下所示：

工作区 暂存区 版本库 解决方式 / 撤销命令
存在 xxx code (无) (无) 1. 手动撤销 —— 不推荐，容易出错

2. git checkout -- [filename] —— 推荐
存在 xxx code 存在 xxx code (无) git reset
存在 xxx code 存在 xxx code 最新版本包含 xxx code

上一版本不包含 xxx code		 前提条件： commit 之后没有 push

命令：git reset

情况一：对于工作区的代码，还没有 add

你当然可以直接删掉你目前在工作区新增的代码，如下所示：

# 向ReadMe中新增⼀⾏代码
echo "This piece of code is like shit" >> ReadMe

# 查看状态
git status

# 使用vim直接删除新增的代码
vim ReadMe

# 查看状态
git status

结果如下：

在这里插入图片描述

幸亏我们工作效率不高，才写了一行代码就发现不行了，要是你写了 3 天，一直都没有提交，该怎么删掉呢？你自己都忘了自己新增哪些，有人会说，我可以 git diff xxx 一下，看看差别在删啊，那你肯定又要花 3 天时间删代码了，并且很大的概率还会改出 bug。一周过去了，你怎么向你的老板交代呢？

Git 其实还为我们提供了更好的方式，我们可以使用 git checkout -- [file] 命令让工作区的文件回到最近一次 add 或 commit 时的状态。要注意 git checkout -- [file] 命令中的 -- 很重要，切记不要省略，一旦省略，该命令就变为其他意思了。

示例如下：

# 向ReadMe中新增3⾏代码
echo "This piece of code is like shit" >> ReadMe
echo "This piece of code is like shit" >> ReadMe
echo "This piece of code is like shit" >> ReadMe

# 查看
cat ReadMe

# 恢复到上⼀次add或commit
git checkout -- ReadMe

# 查看
cat ReadMe

结果如下：

在这里插入图片描述

情况二：已经 add，但没有 commit

如果我现在 add 后保存到了暂存区呢？怎么撤销呢？

# 向ReadMe中新增⼀⾏代码
echo "This piece of code is like shit" >> ReadMe

# 执行add存⼊暂存区
git add ReadMe

# 查看状态
git status

结果如下：

在这里插入图片描述

让我们来回忆一下之前的 git reset 回退命令，该命令如果使用 --mixed 参数，可以将暂存区的内容退回为指定的版本内容，但工作区文件保持不变。那我们就可以回退下暂存区的内容了。

示例如下：

# --mixed 是默认参数，使⽤时可以省略
git reset --mixed HEAD ReadMe

# HEAD: 回退到当前版本
# HEAD^: 回退到上一个版本
# HEAD^^: 回退到上两个版本

用 git status 查看一下，发现现在暂存区是干净的，工作区有修改。

在这里插入图片描述

还记得如何丢弃工作区的修改吗？

# 恢复到上⼀次add或commit
git checkout -- ReadMe

# 查看状态
git status

此时就恢复了，结果如下：

在这里插入图片描述

情况三：已经 add，并且也 commit 了

不要担心，我们可以 git reset --hard HEAD^ 回退到上一个版本！不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。（另外需要注意的是，Git 是分布式版本控制系统，一旦你推送到远程版本库，你就真的惨了……因为撤销的目的就是不影响远程仓库的代码）

示例如下：

# 向ReadMe中新增⼀⾏代码
echo "This piece of code is like shit" >> ReadMe

# 提交
git add ReadMe
git commit -m "modify ReadMe"

# 回退
git reset --hard HEAD^

结果如下：

在这里插入图片描述

12. 删除文件

在 Git 中，删除也是一个修改操作，我们实战一下，如果要删除 file5 文件，怎么搞呢？如果你这样做了：

# 直接删除
rm -rf file5

但这样直接删除是没有用的，反而徒增烦恼，git status 命令会立刻告诉你哪些文件被删除了：

在这里插入图片描述

此时，工作区和版本库就不一致了，要删文件，目前除了要删工作区的文件，还要清除版本库的文件。

一般走到这里，有两种可能：

  • 确实要从版本库中删除该文件；
  • 不小心删错了。

对第二种情况，很明显误删，需要使用 git 来进行恢复，很简单，我们刚学过（删除也是修改）：

git checkout -- file5

对于第一种情况，很明显是没有删完，我们只删除了工作区的文件。这时就需要使用 git rm 将文件从暂存区和工作区中删除，并且 commit：

# 删除file5
git rm file5

# 查看状态
git status

# 提交修改
git commit -m "deleted file5"

# 再次查看状态
git status

可以看到，此时文件就从版本库中被删除了。

在这里插入图片描述

# git # elasticsearch # 大数据
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

avatar 腾讯云开发者社区

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

avatar 腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

avatar 腾讯云开发者社区