Git版本控制工具；集中式和分布式区别；安装Git；Git（初始化本地仓库、记录更新变化的过程、远程仓库和验证、标签tag、分支的使用过程；工作流；远程分支；rebase）

可以参考官方电子文档 Git - book(git-scm.com)

1_版本控制工具

1.1_认识版本控制

什么是版本控制？

• 版本控制的英文是Version control；
• 是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程；
• 版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步；

简单来说，版本控制在软件开发中，可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作。

1.2_版本控制的功能

日常开发，常常面临如下一些问题，通过版本控制可以很好的解决：

• 不同版本的存储管理：

  • 一个项目会不断进行版本的迭代，来修复之前的一些问题、增加新的功能、需求，甚至包括项目的重构；

  • 如果通过手动来维护一系列的项目备份，简直是一场噩梦；

• 重大版本的备份维护： 对于很多重大的版本，会进行备份管理；

• 恢复之前的项目版本： 当开发过程中发生一些严重的问题时，想要恢复之前的操作或者回到之前某个版本；

• 记录项目的点点滴滴： 如果每一个功能的修改、bug的修复、新的需求更改都需要记录下来，版本控制可以很好的解决；

• 多人开发的代码合并： 项目中通常都是多人开发，将多人代码进行合并，并且在出现冲突时更好的进行处理；

1.3_版本控制的历史

版本控制的史前时代（没有版本控制）： 人们通常通过文件备份的方式来进行管理，再通过diff命令来对比两个文件的差异；

CVS（Concurrent Versions System）

• 第一个被大规模使用的版本控制工具，诞生于1985年；
• 由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的，也算是SVN的前身（SVN的出现就是为了取代CVS的）。

SVN（Subversion）

• 因其命令行工具名为svn因此通常被简称为SVN；
• SVN由CollabNet公司于2000年资助并发起开发，目的是取代CVS，对CVS进行了很多的优化；
• SVN和CVS一样，也属于集中式版本控制工具；
• SVN在早期公司开发中使用率非常高，但是目前已经被Git取代；

Git（Linus的作品）

• 早期的时候，Linux社区使用的是BitKeeper来进行版本控制；
• 但是因为一些原因，BitKeeper想要收回对Linux社区的免费授权；
• 于是Linus用了大概一周的时间，开发了Git用来取代BitKeeper；
• Linus完成了Git的核心设计，在之后Linus功成身退，将Git交由另外一个Git的主要贡献者Junio C Hamano来维护；

2_集中式和分布式区别

2.1_集中式版本控制

CVS和SVN都是是属于集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）

• 它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本；
• 协同开发人员通过客户端连接到这台服务器，取出最新的文件或者提交更新；

这种做法带来了许多好处，特别是相较于老式的本地管理来说，每个人都可以在一定程度上看到项目中的其他人正在做些什么。

但是集中式版本控制也有一个核心的问题：中央服务器不能出现故障：

• 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作；
• 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据；

2.2_分布式版本控制

Git是属于分布式版本控制系统（Distributed Version Control System，简称 DVCS）

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

目前在公司开发中都是使用Git来管理项目的，所以接下来会重点学习Git的各种用法；

3_安装Git

3.1_官网下载安装

Git的官网：https://git-scm.com/downloads

根据自己的操作系统下载Git即可；

在window操作系统按照默认配置全局安装即可

3.2_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 命令；

3.3_Git的配置分类

在系统上安装了 Git，需要做几件事来定制Git 环境：

• 每台计算机上只需要配置一次，程序升级时会保留配置信息；
• 可以在任何时候再次通过运行命令来修改它们；

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量：

• /etc/gitconfig 文件：包含系统上每一个用户及他们仓库的通用配置
  • 如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量；
  • 由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它。（开发中通常不修改）
• ~/.gitconfig 或 C/用户/coderwhy/.gitconfig 文件：只针对当前用户。- 你可以传递 --global 选项让 Git 读写此文件，这会对你系统上 所有 的仓库生效；
• 当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对该仓库。- 你可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它；

3.4_Git的配置选项

安装Git后，要做的第一件事就是设置自己的用户名和邮件地址。

• 这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改；
• 如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息；

git config –global user.name “xxx”

git config –global user.email "[email protected] "

检测当前的配置信息：git config --list

3.5_Git的别名（alias）

Git 并不会在你输入部分命令时自动推断出你想要的命令： 如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名

比如

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

比如，以后用status命令，可以直接git st

4_Git初始化本地仓库

Git管理源代码，本地也需要有一个Git仓库。
通常有两种获取 Git 项目仓库的方式：

• 方式一：初始化一个Git仓库，并且可以将当前项目的文件都添加到Git仓库中（目前很多的脚手架在创建项目时都会默认创建一个Git仓库）；
• 方式二：从其它服务器 克隆（clone） 一个已存在的 Git 仓库

方式一：初始化Git仓库

• 该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的核心；

• 但是，在这个时候，仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪；

• git init

方式二：克隆Git远程仓库

git clone https://github.com/xxxxxxxxxx.git

(xxx表示根据实际克隆远程仓库的地址)

5_Git记录更新变化的过程

5.1_文件的状态划分

电脑上已经有一个Git仓库：

• 在实际开发中，需要将某些文件交由这个Git仓库来管理；
• 并且之后会修改文件的内容，当达成某一个目标时，想要记录下来这次操作，就会将它提交到仓库中；

那么需要对文件来划分不同的状态，以确定这个文件是否已经归于Git仓库的管理：

• 未跟踪：默认情况下，Git仓库下的文件也没有添加到Git仓库管理中，需要通过add命令来操作；
• 已跟踪：添加到Git仓库管理的文件处于已跟踪状态，Git可以对其进行各种跟踪管理；

已跟踪的文件又可以进行细分状态划分：

• staged：暂缓区中的文件状态；
• Unmodified：commit命令，可以将staged中文件提交到Git仓库
• Modified：修改了某个文件后，会处于Modified状态；

在开发时，可以选择性地将这些修改过的文件放入暂存区。 然后提交所有已暂存的修改，如此反复；

下图是简化版的Cit文件状态转换图

下图是精致版的Cit文件状态转换图

5.2_检测文件的状态 - git status

在有Git仓库的目录下新建一个文件，查看文件的状态：

Git status

Untracked files：未跟踪的文件

• 未跟踪的文件意味着 Git 在之前的提交中没有这些文件；
• Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”；

也可以查看更加简洁的状态信息： 左栏指明了暂存区的状态，右栏指明了工作区的状态；

5.3_文件添加到暂存区 – git add

跟踪新文件命令：aaa.js只是一个样例。这是演示 git add 开始跟踪一个文件。

git add aaa.js

跟踪修改的文件命令： 如果已经跟踪了某一个文件，这个时候修改了文件也需要重新添加到暂存区中；

如下图所示，将aaa.js文件add后，文件的状态如图左边。然后将aaa.js文件修改，文件状态如图右边。

通过git add . 将所有的文件添加到暂存区中：

5.4_git忽略文件

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

• 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等；
• 可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式；

在实际开发中，这个文件通常不需要手动创建，在必须的时候添加自己的忽略内容即可；

比如创建的Vue项目自动创建的忽略文件：

• 包括一些不需要提交的文件、文件夹；
• 包括本地环境变量文件；
• 包括一些日志文件；
• 包括一些编辑器自动生成的文件；

在github上已经有人整理好，不同类型的项目应该忽略哪些文件，可以直接复制到自己项目的.gitignore文件。这是网址https://github.com/github/gitignore

5.5_文件更新提交 – git commit

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

• 每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了；
• 再运行提交命令 git commit；
• 可以在 commit 命令后添加 -m 选项，将提交信息注释与命令放在同一行;

git commit –m “提交信息注释”

如果修改文件的add操作，加上commit的操作有点繁琐，那么可以将两个命令结合来使用：

git commit -a -m "修改了bbb文件

5.6_Git的校验和

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

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

5.7_查看提交的历史 – git log

在提交了若干更新，又或者克隆了某个项目之后，有时候想要查看一下所有的历史提交记录。

这个时候可以使用git log命令：

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

git log --pretty=oneline 每条日志都只显示一行，多屏显示控制方式空格向下翻页 b向上翻页 q退出

git log --pretty=oneline --graph 展示图形化的提交记录，适用于项目里面有多个分支

5.8_版本回退 – 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

6_Git远程仓库和验证

可以参考一下网上具体的详细步骤 Gitee操作极速上手指南: 使用 Git 进行本地与远程之间的推送，拉取，修改，删除等操作

6.1_远程仓库

什么是远程仓库（Remote Repository）呢？

• 目前的代码是保存在一个本地仓库中，也就意味着只是在进行本地操作；
• 在真实开发中，通常是多人开发的，所以会将管理的代码共享到远程仓库中；

那么如何创建一个远程仓库呢？

• 远程仓库通常是搭建在某一个服务器上的（当然本地也可以，但是本地很难共享）；
• 所以需要在Git服务器上搭建一个远程仓库；

目前有如下方式可以使用Git服务器：

• 使用第三方的Git服务器：比如GitHub、Gitee、Gitlab等等；
• 在自己服务器搭建一个Git服务；

6.2_远程仓库的验证

常见的远程仓库有哪些呢？目前比较流行使用的是三种：

• GitHub：https://github.com/
• Gitee：https://gitee.com/
• 自己搭建Gitlab：http://152.136.185.210:7888/

对于私有的仓库想要进行操作，远程仓库会对的身份进行验证：如果没有验证，任何人都可以随意操作仓库是一件非常危险的事情；

目前Git服务器验证手段主要有两种：

• 方式一：基于HTTP的凭证存储（Credential Storage）；
• 方式二：基于SSH的密钥；

6.3_远程仓库的验证 – 凭证

因为本身HTTP协议是无状态的连接，所以每一个连接都需要用户名和密码：

• 如果每次都这样操作，那么会非常麻烦；
• 幸运的是，Git 拥有一个凭证系统来处理这个事情；

下面有一些 Git Crediential 的选项：

• 选项一：默认所有都不缓存。 每一次连接都会询问你的用户名和密码；
• 选项二：“cache” 模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中，并且在15分钟后从内存中清除；
• 选项三：“store” 模式会将凭证用明文的形式存放在磁盘中，并且永不过期；
• 选项四：如果你使用的是 Mac，Git 还有一种 “osxkeychain” 模式，它会将凭证缓存到你系统用户的钥匙串中（加密的）；
• 选项五：如果你使用的是 Windows，你可以安装一个叫做 “Git Credential Manager for Windows” 的辅助工具；
  • 可以在 https://github.com/Microsoft/Git-Credential-Manager-for-Windows 下载
  • 在终端输入命令：git config credential.helper
  • 若终端回馈：manager-core 。则表明设置成功。

6.4_远程仓库的验证 – SSH密钥

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

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

如果以SSH的方式访问Git仓库，那么就需要生产对应的公钥和私钥：

ssh-keygen -t ed25519 -C “your email"
ssh-keygen -t rsa -b 2048 -C “your email"

6.5_管理远程服务器

查看远程地址：比如之前从GitHub上clone下来的代码，它就是有自己的远程仓库的：

git remote
git remote –v
-v是—verbose的缩写(冗长的)

添加远程地址：也可以继续添加远程服务器（让本地的仓库和远程服务器仓库建立连接）：

git remote add

比如说： git remote add gitTest https://xxxxxxxxxxxxxxxx.git

重命名远程地址：

git remote rename gitlab glab

移除远程地址：

git remote remove gitlab

6.6_本地分支的上游分支（跟踪分支）

输入git pull 出现问题——当前分支没有track的分支

问题的原因：当前分支没有和远程的origin/master分支进行跟踪。

• 在没有跟踪的情况下，直接执行pull操作的时候必须指定从哪一个远程仓库中的哪一个分支中获取内容
• 比如说，可以这样设置 git pull origin master 。

想要直接执行git fetch是有一个前提的：

• 必须给当前分支设置一个跟踪分支
• 比如这样设置：git branch –set-upstream-to=origin/master
  再输入git pull

6.7_拒绝合并不相干的历史

按照6.6的办法设置，再输入git pull

又出现问题——拒绝合并不相干的历史

fatal : refusing to merge unrelated histories

再比如说，输入git merge ，仍然出现这个问题。

究其原因，是因为，将两个不相干的分支进行合并。

参考网上的答案 https://stackoverflow.com/questions/37937984/git-refusing-to-merge-unrelated-histories-on-rebase#comment69918373_37937984

简单来说就是：过去git merge允许将两个没有共同基础的分支进行合并，这导致了一个后果：新创建的项目可能被一个毫不怀疑的维护者合并了很多没有必要的历史，到一个已经存在的项目中，目前这个命令已经被纠正，但是依然可以通过--allow-unrelated-histories选项来逃逸这个限制，来合并两个独立的项目

git merge --allow-unrelated-histories

6.8_远程仓库的交互

从远程仓库clone代码：将存储库克隆到新创建的目录中；

git clone http://xxxxxxxx.git

将代码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 + git merge(rebase)

6.9_合并冲突（conflict）

通过pull从Git远程仓库获取到分支内容后会自动进行合并（merge）

但是并非所有的情况都可以正常的合并，某些情况下合并会出现冲突

6.10_常见的开源协议

一般首先推荐使用MIT许可证，其次是BSD许可证

7_Git标签tag

7.1_创建tag

对于重大的版本常常会打上一个标签，以表示它的重要性：

• Git 可以给仓库历史中的某一个提交打上标签；
• 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）；

创建标签：

• Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）；
• 附注标签：通过-a选项，并且通过-m添加额外信息；

比如说

git tag v1.0

git tag -a v1.1 -m “额外信息”

默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签；

git push origin v1.0

git push origin –tags

7.2_删除和检出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

8_Git分支的使用过程

8.1_Git提交对象（Commit Object）

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着可以把自己的工作从开发主线上分离开来，以免影响开发主线。

在进行提交操作时，Git 会保存一个提交对象（commit object）：

• 该提交对象会包含一个指向暂存内容快照的指针；

• 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针；

  • 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象；
  • 而由多个分支合并产生的提交对象有多个父对象；

  

8.2_Git master分支

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

• Git 的默认分支名字是 master，在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支；
• master 分支会在每次提交时自动移动；

Git 的 master 分支并不是一个特殊分支。

• 它就跟其它分支完全没有区别；
• 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它；

下图的白色方块，是每次commit提交创建的对象文件。

8.3_Git创建分支

Git 创建新分支，，只是创建了一个可以移动的新的指针；

比如，创建一个 testing 分支， 需要使用 git branch 命令：

git branch testing

Git 是通过一个名为 HEAD 的特殊指针，知道当前在哪一个分支上

git checkout testing

8.4_Git分支提交

如果指向某一个分支，并且在这个分支上提交：

也可以切换回到master分支，继续开发：

创建分支同时切换

在创建一个新分支后立即切换过去，用 git checkout -b <newbranchname> 命令搞定

8.5_分支的由来

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

• 开发某个项目，在默认分支master上进行开发；
• 实现项目的功能需求，不断提交；
• 并且在一个大的版本完成时，发布版本，打上一个tag v1.0.0；

继续开发后续的新功能，但是，突然有个很严重的问题需要紧急修补， 你将按照如下方式来处理： 切换到tag v1.0.0的版本，并且创建一个分支hotfix；

想要新建一个分支并同时切换到那个分支上，你可以运行一个带有 -b 参数的 git checkout 命令：

git checkout –b hotfix

8.6_分支开发和合并

分支上开发、修复bug：

• 可以在创建的hotfix分支上继续开发工作或者修复bug；

• 当完成要做的工作后，重新打上一个新的tag v1.0.1；

切换回master分支，但是这个时候master分支也需要修复刚刚的bug，所以需要将master分支和hotfix分支进行合并；

git checkout master
git merge hotfix

8.7_查看和删除分支

希望查看当前所有的分支，可以通过以下命令：

git branch # 查看当前所有的分支
git branch –v # 同时查看最后一次提交
git branch --merged # 查看所有合并到当前分支的分支
git branch --no-merged # 查看所有没有合并到当前分支的分支

如果某些已经合并的分支不再需要了，那么可以将其移除掉：
查看和删除分支

git branch –d hotfix # 删除当前分支
git branch –D hotfix # 强制删除某一个分支

9_Git的工作流（git flow）

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

• 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支；
• 你可以定期地把某些主题分支合并入其他分支中；

比如以下的工作流：

• master作为主分支；
• develop作为开发分支，并且有稳定版本时，合并到master分支中；
• topic作为某一个主题或者功能或者特性的分支进行开发，开发完成后合并到develop分支中；

下图是常用的工作流

10_Git的远程分支

远程分支是也是一种分支结构，是 以 <remote>/<branch> 的形式命名的；

如果刚刚clone下来代码，分支的结构如下：

如果其他人修改了代码，那么远程分支结构如下：你需要通过fetch来获取最新的远程分支提交信息；

**远程分支的管理**

操作一：推送分支到远程

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

branch指的是分支的名字

git push origin

操作二：跟踪远程分支

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

git checkout --track /
git checkout

操作三：删除远程分支。如果某一个远程分支不再使用，想要删除掉，可以运行带有 --delete 选项的 git push 命令来删除一个远程分支。

git push origin --delete

11_Git rebase

11.1_rebase用法

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。

什么是rebase呢？

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

git checkout experiment

git rebase master

11.2_rebase原理

• 首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master） 的最近共同祖先 C2；

• 然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件；

• 然后将当前分支指向目标基底 C3；

• 最后以此将之前另存为临时文件的修改依序应用；

再次执行master上的合并操作：

git checkout master
git merge experiment

11.3_rebase和merge的选择

事实上，rebase和merge是对Git历史的不同处理方法：

• merge用于记录git的所有历史，那么分支的历史错综复杂，也全部记录下来；
• rebase用于简化历史记录，将两个分支的历史简化，整个历史更加简洁；

了解了rebase的底层原理，就可以根据自己的特定场景选择merge或者rebase。

注意：rebase有一条黄金法则——永远不要在主分支上使用rebase

• 如果在main上面使用rebase，会造成大量的提交历史在main分支中不同；

• 而多人开发时，其他人依然在原来的main中，对于提交历史来说会有很大的变化；

下图是一张简易的Git命令总结图