2024年大数据最新git入门（必看）(1)，如果不想35岁被淘汰这篇文章必看

2024-06-12 开源 0

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

		* [git cherry-pick 转移多个提交](#git_cherrypick__696)		* [git cherry-pick 配置项](#git_cherrypick__719)		* [git cherry-pick 转移到另一个代码库](#git_cherrypick__732)		* [git cherry-pick 代码冲突](#git_cherrypick__762)	- [查看远程分支](#_790)	- [推送分支](#_810)	- [抓取分支](#_833)	- [git rebase](#git_rebase_882)

什么是“版本控制”？我为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。在CODE CHINA 中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

接下来，我们将要回顾版本控制系统的发展历史。

版本控制系统发展可以分为三个阶段：

本地版本控制系统
- 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
  为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
  其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
集中化的版本控制系统
- 接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
  这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
  但这么做也有一个显而易见的缺点，那就是是中央服务器的单点故障。 - 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作 - 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。
  本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
分布式的版本控制系统
- 于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来，包括完整的历史记录。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
  不仅如此，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。这样一来，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

Git 的诞生

接下来，让我们来看一看 Git 诞生的故事。

Git 诞生的背景

同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。

Linus 在1991年创建了开源的 Linux，从此，Linux 系统不断发展，已经成为最大的服务器系统软件了。在1991－2002年期间，世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus，然后由 Linus 本人通过手工方式合并代码。

你也许会想，为什么 Linus 不把 Linux 代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus 坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和 Linux 的开源精神不符。

Linus 两周完成 Git

到 2002 年，Linux 系统已经发展了十年了，代码库之大让 Linus 很难继续通过手工方式管理了，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码，BitKeeper 的东家 BitMover 公司也免费授权 Linux 社区使用这个版本控制系统。后来 BitMover 公司发现社区有人试图破解 BitKeeper 的协议，于是 BitMover 公司收了回 Linux 社区的免费使用权。

这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。他们对新的系统制订了若干目标：

速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

于是，Linus 花了两周时间自己用 C 写了一个分布式版本控制系统，这就是 Git！一个月之内，Linux 系统的源码已经由 Git 管理了！

Git 的发展壮大

自 2005 年诞生以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统。Git 迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub 网站上线了，它为开源项目免费提供 Git 存储，无数开源项目开始迁移至 GitHub ，包括jQuery，PHP，Ruby等等。

git安装

Git安装在你开始使用 Git 前，需要将它安装在你的计算机上。即便已经安装，最好将它升级到最新的版本。你可以通过软件包或者其它安装程序来安装，或者下载源码编译安装。下面，我们将会介绍不同操作系统上 Git 的安装方法。

在 Windows 上安装

在 Windows 上安装 Git 的方法如下：
使用官方版本安装
官方版本可以在 Git 官方网站下载。打开 https://git-scm.com/download/win，然后选择相应的版本即可。

在 macOS 上安装

在 Mac 上安装 Git 有多种方式。
最简单的方法是安装 Xcode Command Line Tools。 Mavericks （10.9）或更高版本的系统中，在 Terminal 里尝试首次运行 git 命令即可。 bash $ git --version 如果没有安装过命令行开发者工具，将会提示你安装。如果你想安装更新的版本，可以使用二进制安装程序。官方维护的 macOS Git 安装程序可以在 Git 官方网站下载，网址为 https://git-scm.com/download/mac。

在 Linux 上安装

在 Linux 上用二进制安装程序来安装基本的 Git 工具，可以使用发行版包含的基础软件包管理工具来安装。以 Fedora 为例，如果你在使用它（或与之紧密相关的基于 RPM 的发行版，如 RHEL 或 CentOS），你可以使用 dnf： bash $ sudo dnf install git-all 如果你在基于 Debian 的发行版上，如 Ubuntu，请使用 apt： bash $ sudo apt install git-all 要了解更多选择，Git 官方网站上有在各种 Unix 发行版的系统上安装步骤，网址为 https://git-scm.com/download/linux。

Git环境配置

好了，当你当完成了 Git 的安装后，接下来我们就需要对 Git 进行一些必要的环境配置。通常情况下，每台计算机上只需要配置一次 Git，当 Git 程序升级时会保留配置信息。你可以在任何时候再次通过运行 git config命令来修改它们。
git config
Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。接下来，我们先学习如何通过 git config 命令来配置 用户信息

配置用户名和邮件地址

安装完 Git 之后，要做的第一件事就是设置你的用户名和邮件地址。这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改：

git config --global user.name "李老师"git config --global user.email li@csdn.net

再次强调，如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息。

当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 --global 选项的命令来配置。

检查配置

如果想要检查你的配置，可以使用 git config --list 命令来列出所有 Git 当时能找到的配置。

git config --list

Git 颜色配置

到目前为止，我们已经配置了 user.name 和 user.email ，实际上，Git 还有很多可配置项。比如，让 Git 显示颜色，会让命令输出看起来更醒目：

git config --global color.ui true

Git 显示颜色
这样，Git 会适当地显示不同的颜色，比如使用git status命令后文件名就会标上颜色。

Git忽略文件配置

有些时候，你必须把某些文件放到 Git 工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件等等，每次git status都会显示Untracked files ...，这种情况下，就可以实用忽略特殊文件 .gitignore 来很方便的解决这个问题。首先我们在 Git 工作区的根目录下创建一个特殊的 .gitignore文件，然后把要忽略的文件名填进去，Git 在每次进行提交的时候就会自动忽略这些文件。
忽略文件的规则
日常使用中，我们一般不需要从头开始编辑.gitignore文件，已经有各种现成的种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://codechina.csdn.net/codechina/gitignore
忽略文件的原则是：

忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

强制添加被忽略文件

git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -f if you really want to add them.

如果你确实想添加该文件，可以用-f强制添加到 Git：

git add -f App.class

或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：
检查忽略规则

git check-ignore -v App.class.gitignore:3:*.class App.class

Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
还有些时候，当我们编写了规则排除了部分文件时：
bash # 排除所有.开头的隐藏文件: .* # 排除所有.class文件: *.class
但是我们发现.*这个规则把.gitignore也排除了，并且App.class需要被添加到版本库，但是被*.class规则排除了。
添加例外规则
这个时候，虽然可以用git add -f强制添加进去，但我们建议你可以添加两条例外规则：
bash # 排除所有.开头的隐藏文件: .* # 排除所有.class文件: *.class # 不排除.gitignore和App.class: !.gitignore !App.class 把指定文件排除在.gitignore规则外的写法就是!+文件名，所以，只需把例外文件添加进去即可。

配置 git log -1

配置一个git last，让其显示最后一次提交信息：

git config --global alias.last 'log -1'

这样，用git last就能显示最近一次的提交：

git last commit 4aac6c7ee018f24d2dabfd01a1e09c77612e1a4e (HEAD -> master) Author: Miykael_xxm Date: Tue Nov 17 11:14:15 2020 +0800 branch test

配置 git lg

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

以上这些就是 git 常用的一些配置了。

Git 配置文件

这些自定义的Git配置文件通常都存放在仓库的.git/config文件中：

全局配置文件

cat .git/config

别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。而当前用户的 Git 配置文件放在用户主目录下的一个隐藏文件.gitconfig中：

git使用

创建目录

初始化仓库

git init

瞬间 Git 就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），同时在当前目录下多了一个.git的目录，这个目录是 Git 来跟踪管理版本库的，如果你没有看到 .git 目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看到了。

克隆现有的仓库

git clone <url>

自定义本地仓库名称

当然如果你想在克隆远程仓库的时候，自定义本地仓库的名字也是可以的，你可以通过额外的参数指定新的目录名：

git clone https://codechina.csdn.net/codechina/help-docs mydocs

这会执行与上一条命令相同的操作，但目标目录名变为了 mydocs。

Git 支持多种数据传输协议。上面的例子使用的是 https:// 协议，不过你也可以使用 git:// 协议或者使用 SSH 传输协议，比如 user@server:path/to/repo.git 。

编辑并添加文件

接下来，我们来尝试在已经准备好的 Git 仓库中编辑一个readme.txt文件，内容如下：

bash Git is a version control system. Git is free software.

接下来，我们可以通过2个命令将刚创建好的readme.txt添加到Git仓库：

第一步，用命令git add告诉 Git，把文件添加到仓库：

git add readme.txt

执行上面的命令，没有任何显示，说明添加成功。

提交变动到仓库

第二步，用命令git commit告诉 Git，把文件提交到仓库：

git commit -m "wrote a readme file" [main aac23f0] wrote a readme file 1 file changed, 1 insertion(+) create mode 100644 readme.txt

这里简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你：

1 file changed：1个文件被改动（我们新添加的readme.txt文件）
1 insertions：插入了一行内容（readme.txt有一行内容）
为什么 Git 添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

git add file1.txt $ git add file2.txt file3.txtgit commit -m "add 3 files."

查看Git仓库当前状态变化

我们已经成功地添加并提交了一个readme.txt文件，接下来让我们继续修改readme.txt文件，改成如下内容：

bash Git is a distributed version control system. Git is free software.

现在，运行git status命令看看结果：

git status On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory)modified:   readme.txtno changes added to commit (use "git add" and/or "git commit -a")

注意，git restore和git checkout具有相同的效果，现在最新的使用的是git restore

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
在这里插入图片描述

比较变动

虽然 Git 告诉我们readme.txt被修改了，但并没有告诉我们具体修改的内容是什么，假如刚好是上周修改的，等到周一来班时，已经记不清上次怎么修改的readme.txt，这个时候我们就需要用git diff这个命令查看相较于上一次暂存都修改了些什么内容了：

运行 git diff 命令

git diff readme.txt

在这里插入图片描述

git diff顾名思义就是查看 difference，显示的格式正是 Unix 通用的 diff 格式，可以从上面的输出看到，我们在第一行添加了一个distributed单词。

综合操作

知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add：

git add readme.txt

同样没有任何输出。在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

git statusOn branch master Changes to be committed: (use "git reset HEAD ..." to unstage)modified:   readme.txt

git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：

git commit -m "add distributed" [master e55063a] add distributed 1 file changed, 1 insertion(+), 1 deletion(-)

提交后，我们再用git status命令看看仓库的当前状态：

git status

在这里插入图片描述

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。

查看日志

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

git log --pretty=oneline

在这里插入图片描述

每提交一个新版本，实际上 Git 就会把它们自动串成一条时间线。如果使用可视化工具或者之前在 git 自定义配置中介绍的 git lg命令，就可以更清楚地看到提交历史的时间线：

git lg

在这里插入图片描述

作为一个优秀的版本控制系统，Git 能够让我们查看每一次提交的记录。在日常的工作中，我们可以随时对 Git 仓库中的内容进行修改，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在 Git中被称为commit / 提交。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

git log

在 Git 中，我们可以通过git log命令查看全部的commit记录：
在这里插入图片描述

git log命令显示从最近到最远的提交日志，我们可以看到2次提交，最近的一次是add distributed，最早的一次是wrote a readme file。

Git 回退

这个时候，假设我们需要将 readme.txt 回退到上一个版本，也就是 wrote a readme file 的这个版本，我们需要怎么操作呢？

首先，Git 必须知道当前版本是哪个版本，在 Git 中，用HEAD表示当前版本，也就是最新的提交e55063a，上一个版本就是HEAD^，上上一个版本就是HEAD ^^，当然往上100个版本写100个 ^比较容易数不过来，所以写成HEAD~100。

现在，我们要把当前版本add distributed回退到上一个版本wrote a readme file，就可以使用git reset命令：

git reset --hard HEAD^HEAD is now at aac23f0 wrote a readme file

现在让我们看看readme.txt的内容是不是版本wrote a readme file：

cat readme.txt Git is a version control system. Git is free software.

果然还原到最初wrote a readme file这个版本了。

Git 的版本回退速度非常快，因为 Git 在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git 仅仅是把HEAD从指向add distributed：

HEAD 指针移动记录

┌────┐ │HEAD│ └────┘ │ └──> ○ add distributed │ ○ wrote a readme file 改为指向wrote a readme file： ┌────┐ │HEAD│ └────┘ │ │ ○ add distributed │ │ └──> ○ wrote a readme file

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

Git重置

现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

好在 Git 提供了一个命令git reflog用来记录你的每一次命令，当你用git reset --hard HEAD^回退到wrote a readme file版本时，再想恢复到add distributed，就可以通过git reflog命令找到add distributed的commit id。

git reflogaac23f0 (HEAD -> main) HEAD@{0}: reset: moving to HEAD^ca5f957 HEAD@{1}: commit: add distributedaac23f0 (HEAD -> main) HEAD@{2}: commit: wrote a readme file148737e (origin/main, origin/HEAD) HEAD@{3}: clone: from https://github.com/xxxx-sky/AudioGPT

从上面的输出可以看到，add distributed的commit id是ca5f957，现在，我们就可以通过 git reset --hard ca5f957切换到最新的版本上了。

工作区和暂存区

Git 和其他版本控制系统如 SVN 的一个不同之处就是有暂存区的概念。

工作区（Working Directory）

就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：
在这里插入图片描述

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是 Git 的版本库。

Git 的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有 Git 为我们自动创建的第一个分支master，以及指向 master 的一个指针叫HEAD。
在这里插入图片描述

前面讲了我们把文件往 Git 版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建 Git 版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往 master 分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

现在，我们来试一下，先对readme.txt做个修改，比如加上一行内容：

bash Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage.

然后，在工作区新增一个LICENSE文本文件。

先用git status查看一下状态：

git status On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory)modified:   readme.txtUntracked files: (use "git add ..." to include in what will be committed)LICENSEno changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。

现在，使用两次命令git add，把readme.txt和LICENSE都添加后，用git status再查看一下：

git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage)new file:   LICENSEmodified:   readme.txt

现在，暂存区的状态就变成这样了：
在这里插入图片描述

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

git commit -m "understand how stage works" [master 599dbdb] understand how stage works 2 files changed, 2 insertions(+) create mode 100644 LICENSE

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

git status On branch master nothing to commit, working tree clean

现在版本库变成了这样，暂存区就没有任何内容了：

在这里插入图片描述

撤销修改

git commit --amend

当你在修补最后的提交时，并不是通过用改进后的提交原位替换掉旧有提交的方式来修复的，理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。
修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史。

 git commit -m 'initial commit'  git add forgotten_file  git commit --amend

取消暂存的文件

git reset HEAD
git restore --staged

已知有这两种方法，当前git add添加到缓存区之后提示的是第二种方法
在这里插入图片描述

git reset方法：
在这里插入图片描述

git restore方法：
在这里插入图片描述

撤销对文件的修改

git checkout方法：
在这里插入图片描述

git restore方法：
在这里插入图片描述

删除/还原文件

本地删除文件
在这里插入图片描述

git add test.txt git commit -m "remove test.txt"

在这里插入图片描述

删除文件另一种方法：

git rm

先手动删除文件，然后使用git rm 和git add效果是一样的。

还原文件（本地删除，但已经commit的文件）

git checkout --

在这里插入图片描述

分支管理

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。

有人把 Git 的分支模型称为它的“必杀技特性”，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。为何 Git 的分支模型如此出众呢？ Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

git分支简介

为了真正理解 Git 处理分支的方式，我们需要回顾一下 Git 是如何保存数据的。

前面我们了解到，Git 保存的不是文件的变化或者差异，而是一系列不同时刻的快照。

在进行提交操作时，Git 会保存一个提交对象（commit object）。知道了 Git 保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象，

为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。暂存操作会为每一个文件计算校验和，然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交：

git add readme.txt test.md LICENSE git commit -m 'The initial commit of my project'

当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。

现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。
在这里插入图片描述