git：图解分支

红太狼 2023-01-11 08:43 267阅读 0赞

> 在开发软件时，可能有多个人同时为一个软件开发，可能同时存在多个release版本，并且需要对各个版本进行维护，而git的分支功能就可以支持**同时**进行多个功能的开发和版本管理

# 什么是分支 #

>  *  git仓库的所有提交节点之间的关系，其实就是一棵树。所以一个分支也可以看成是树上的一条链路。
>  *  如果说分支是一条链路的话，那么这个链路上的每一个节点就是一个commit提交，commit提交相当于快照或者游戏存档  
>     一个branch上有多个commit，一个游戏也可以有多个存档，但是当下显然只能加载一个。所以git当中用一个指针指向当前加载的commit，也就是说纵向来看一个分支代表的是一连串的提交，但在**git当中我们使用的分支其实是一个指针**，一个在commit当中切换的指针

一开始的时候我们只有默认分支master，它指向当前的一个提交  
![在这里插入图片描述][20210208115112802.png]  
现在我们使用git branch test命令创建一个测试分支，执行之后，其实只不过是多了一个指针也指向当前的commit。git当中的结构变成这样：  
![在这里插入图片描述][20210208115129856.png]  
当我们在test分支上做了改动提交之后，git会产生一个新的提交，并且移动test指针，而master指针会留在原地  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]  
如果我们再回到master也进行了改动和提交之后，又会产生新的节点，并且这个节点会和test的节点区分开，形成新的链路，于是就形成了一棵树的样子  
![在这里插入图片描述][20210208115202473.png]

# 创建分支 #

`git branch + 分支名字`就可以创建分支，实质上，git内部会创建一个新的指针指向当前的commit。分支本质上是一个指针。

## 理论 ##

> **git branch<分支名>** 创建分支  
> **git checkout<分支名>** 切换到分支  
> **git checkout -b <分支名>** 创建一个分支并切换到新的分支

*  git 的分支只是简单的指向某个提交记录
 *  分支相当于：“我想基于这个提交以及它的所有父提交进行新的工作”
 *  **早建分支|多用分支**：这是因为即使创建再多的分支也不会造成储存或者内存上的开销，并且按逻辑分解工作到不同的分支比维护那些特别臃肿的分支简单多了

> **`git branch`** ：显示当前所有（本地）的分支。 前面有\*表示当前分支  
> `git branch -a`：查看全部分支(包含本地和远程)

$ git branch
      iss53
    * master
      testing

*  这意味着如果在这时候提交，master 分支将会随着新的工作向前移动

> `git branch -v`：查看每一个（本地）分支的最后一次提交

$ git branch -v
      iss53   93b412c fix javascript issue
     * master  7a98805 Merge branch 'iss53'
      testing 782fd34 add scott to the author list in the readmes

> `git branch --merged`：查看哪些（本地）分支已经合并到当前（本地）分支

$ git branch --merged
      iss53
     * master

*  因为之前已经合并了 iss53 分支，所以现在看到它在列表中。
 *  在这个列表中分支名字前没有 \* 号的分支通常可以使用 `git branch -d`删除掉：你已经将它们的工作整合到了另一个分支，所以并不会失去任何东西。

> `git branch --no-merged`： 查看哪些（本地）分支还没有合并到当前（本地）分支

*  因为它包含了还未合并的工作，尝试使用 git branch -d 命令删除它时会失败：

$ git branch -d testing  # 删除本地已合并的分支
    error: The branch 'testing' is not fully merged.
    If you are sure you want to delete it, run 'git branch -D testing'.

*  如果真的想要删除分支并丢掉那些工作，如同帮助信息里所指出的，可以使用 -D 选项强制删除它。

> 上面描述的选项 `--merged` 和 `--no-merged` 会在没有给定提交或分支名作为参数时， 分别列出已合并或未合并到 当前 （本地）分支的（本地）分支。

*  你总是可以提供一个附加的参数来查看其它分支的合并状态而不必检出它们。 例如，尚未合并到 master 分支的有哪些？

$ git checkout testing
    $ git branch --no-merged master
      topicA
      featureB

> 删除本地已合并的分支： `git branch -d [branchname]`  
> 删除远程分支: `git push origin --delete [branchname]`
> 
>  *  在删除远程分支时，同名的本地分支并不会被删除，所以还需要单独删除本地同名分支

> 清理本地无效分支(远程已删除本地没删除的分支): `git fetch -p`  
> 如果分支太多，还可以用此命令进行分支模糊查找: `git branch | grep 'branchName'`

## 实践 ##

接下来让我们看看分支是怎么样子的

> 如下图Git仓库中：
> 
>  *  当前有两个提交记录
>     
>      *  初始提交`C0`
>      *  其后可能包含某些有用修改的提交`C1`
>  *  当前位于main分支上

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]

> 接下来我们通过命令`git branch newImage`创建一个名字叫做newImage的分支。效果是
> 
>  *  创建一个分支`newImage`
>  *  新创建的分支指向的是当前的快照(提交记录)`C1`

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]

> 接下来，我们试着往新分支中提交一些东西：`git commit`
> 
>  *  效果：
>     
>      *  main分支前进了，新分支还是指向之前的提交记录
>  *  原因：
>     
>      *  提交之前位于main分支，所以`git commit`是对main分支进行操作
>  *  解决：
>     
>      *  我们应该先切换到新分支上在进行提交
>      *  切换分支的命令是：`git checkout <name>`， 比如说：git checkout newImage\*\*

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]

> 接下来我们看看**先切换到新分支然后提交**是怎样的效果。 执行命令：`git checkout newImage; git commit`
> 
>  *  效果：
>     
>      *  切换到了新分支newImage，
>      *  生成了一个新的提交记录`C2`，新分支newImage指向了当前的提交记录`C2`，也就是说修改已经保存在新分支中了
>      *  PS：
>         
>          *  当然，如果你想创建一个新分支同时切换到新创建的分支，可以执行命令：`git checkout -b <you branch-name>`

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]

> 我们在看下切换到main分支然后在进行提交的效果：`git checkout main; git commit`
> 
>  *  效果：
>     
>      *  切换到了main分支上
>      *  生成了一个新的提交记录`C3`，这个提交记录继承自`C1`，main分支指向这个新生成的提交记录`C3`

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]

# 分支的切换与HEAD #

有一个问题是git怎么知道我们当前的代码在哪里呢？即使知道了代码在哪个分支上，又怎么确定在哪一个节点呢？其实git内部还有一个特殊的指针叫做HEAD。

`HEAD`指向的是现在使用中的分支的最后一次更新。

*  通常默认指向master分支的最后一次更新
 *  通过移动HEAD，就可以变更使用的分支

当我们提交代码的时候，不止只有分支的这些指针会往前移动，HEAD指针也会随着移动。

我们可以通过`git checkout`切换到任意分支，任意节点位置(通过commit id来确定节点位置)

进行`checkout`后，git会从工作树还原向目标分支提交的修改内容，checkout之后的提交记录将被追加到目标分支。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]

# 合并分支 #

> 目标：新建一个分支，在其上开发某个新功能，开发完成之后合并回主线

有两种方法：

*  git merge
 *  git rebase

## git merge ##

在git中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。相当于：我要把两个父节点本身以及它们所有的祖先都包含进来。

### 实践一 ###

> 当前git仓库如下图：
> 
>  *  当前有两个分支，每个分支上各自有一个独有的提交：
>     
>      *  bugFix分支上的人做了一些修改，然后生成提交记录`C2`
>      *  main分支上的人做了另一些修改，然后生成提交记录`C3`
>  *  这意味着没有一个分支包含了我们修改的所有内容
>  *  当前位于main分支上

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]

> 如果我们想要某个分支中包含全部的修改，可以通过**合并这两个分支**来实现。一共需要两步（当前位于main分支上）：
> 
>  *  先将bugFix分支合并到main分支里`git merge bugFix` （当前位于mian分支上，因此直接执行git merge bugFix就可以）
>  *  再将main分支合并到bugFix分支里`git checkout bugFix; git merge main`（当前位于main分支上，如果要对bugFix分支做操作，需要先切换到bugFix上才能对bugFix分支操作）

> 我们先把**将bugFix分支合并到main分支里**。也就是说我们需要在`mian`分支上执行命令`git merge bugFix`：
> 
>  *  效果：  
>     \* 生成了一个提交记录`C4`， 因为我们是在main分支上执行的，所以mian分支会指向新生成的这个提交记录`C4`
>     
>      *  新生成的提交记录`C4`有两个父节点：
>         
>          *  之前main指向的提交记录`C3`
>             
>              *  bugFix当前正指向的提交记录`C2`
>      *  从而，如果从`main`分支开始沿着箭头向上看，在到达起点的路上会经过所有的提交记录。这意味着`main`分支包含了对代码库的所有修改。 也就是说main分支继承了bugFix分支的所有修改

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 8]

> 我们先把**将main分支合并到bugFix分支里**。也就是说我们需要在`bugFix`分支上执行命令`git merge main`。因为当前位于main分支上，我们必须先跳转到bugFix分支上，然后在请求合并命令：`git checkout bugFix; git merge main`
> 
>  *  效果：  
>     \* 因为`main`继承自bugFix，所以git什么都不用做，只需要把`bugFix`移动到当前mian指向的提交记录上就可以了

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 9]

git branch bugFix   //创建新分支bugFix
    git checkout bugFix // 切换到新分支bugFix
    git commit          // 提交
    git checkout main   // 切换到分支main
    git commit          // 提交
    git merge bugFix    // 合并bugFix到main

### 实践二 ###

如下图所示，bugfix分支是从master分支分叉出来的。

![在这里插入图片描述][20210208120935891.png]  
我们需要合并 bugfix分支到master分支

*  如果master分支的状态没有被更改过，那么这个合并是非常简单的。
    
     *  因为bugFix分支的历史记录包含`master`分支所有的历史记录
     *  所以通过把master分支的位置移动到bugFix的最新分支上，git就会合并
     *  这样的合并被称为fast-forward（快进）合并。  
        ![在这里插入图片描述][20210220145541199.png]
     *  执行合并时，如果设定了non fast-forward选项，即使在能够fast-forward合并的情况下也会生成新的提交并合并。

![在这里插入图片描述][20210208121139857.png]

*  如果master分支的历史记录有可能在bugfix分支分叉出去后有新的更新。
    
     *  这种情况下，要把master分支的修改内容和bugfix分支的修改内容汇合起来：  
        ![在这里插入图片描述][20210208121104542.png]
     *  因此，合并两个修改会生成一个提交。
     *  这时，master分支的HEAD会移动到该提交上。  
        ![在这里插入图片描述][20210208121123670.png]

## rebase ##

*  rebase实际上是取出一系列的提交记录，“复制”它们。然后在另外一个地方逐个放下去
 *  rebase的优势是可以创建更线性的提交历史。
    
     *  只允许使用rebase的话，代码库的提交历史将变得十分清晰。
     *  使用rebase可以将某个分支上的工作直接移动到另一个分支上，移动之后会使得两个分支的功能看起来像是顺序开发的，但是实际上它们是并行开发的

### 实践一 ###

> 当前git仓库如下图：
> 
>  *  当前有两个分支，每个分支上各自有一个独有的提交：
>     
>      *  bugFix分支上的人做了一些修改，然后生成提交记录`C2`
>      *  main分支上的人做了另一些修改，然后生成提交记录`C3`
>  *  这意味着没有一个分支包含了我们修改的所有内容
>  *  当前位于bugFix分支上

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 10]

> 如果我们想要某个分支中包含全部的修改，可以通过**合并这两个分支**来实现。一共需要两步（当前位于bugFix分支上）：
> 
>  *  将bugFix分支里的工作移动到main分支上`git checkout bugFix; git rebase main`
>  *  将main分支里的工作移动到bugFix分支上`git checkout main; git rebase bugFix`

> 我们想要把bugFix分支里的工作直接移动到main分支上。
> 
>  *  执行命令：`git rebase main`
>  *  因为当前位于bugFix上，所以上面的命令可以看成是将bugFix上的提交记录（也就是快照）放（复制）到main分支上
>  *  效果：  
>     \* 在main分支的最顶端生成了一个提交记录`C3'`，`C3'`可以看成是由bugFix指向的提交记录`C3`复制来的
>     
>      *  注意，提交记录C3依旧存在（树上那个半透明的节点）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 11]

> 更新main分支 `git checkout main; git rebase bugFix`
> 
>  *  效果：
>  *  因为bugFix继承自main，所以Git只是简单的把main分支的引用向前移动了一下而已

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 12]

> git rebase bugFix; 将C2复制一份到C5

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 13]

### 实践二 ###

如下图所示，bugfix分支是从master分支分叉出来的：  
![在这里插入图片描述][20210208121646644.png]  
如果使用rebase方法进行分支合并：

*  首先，rebase bugFix分支到master分支，bugFix分支的历史记录会添加到master分支的后面  
    ![在这里插入图片描述][20210220145647170.png]
 *  这时移动提交X和Y有可能会发生冲突，所以需要修改各自的提交时发生冲突的部分。  
    ![在这里插入图片描述][20210220145714447.png]
 *  rebase之后，master的HEAD位置不变。因此，要合并master分支和bugfix分支，即是将master的HEAD移动到bugfix的HEAD这里。  
    ![在这里插入图片描述][20210220145738825.png]

# 总结：分支的作用 #

*  分支是为了将修改记录的整体流程分叉保存。
 *  分叉后的分支不受其他分支的影响，所以在同一个仓库中可以同时进行多个修改

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 14]

*  为了不受其他开发人员的影响，在主分支上建立自己专用的分支。
 *  完成工作后，将自己分支上的修改合并到主分支。
 *  因为每一次提交的历史记录都会被保存，所以当发生问题时，定位和修改造成问题的提交就容易多了  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 15]

[https://www.zhihu.com/search?type=content&q=git%E5%AD%A6%E4%B9%A0][https_www.zhihu.com_search_type_content_q_git_E5_AD_A6_E4_B9_A0]

[20210208115112802.png]: /images/20221119/2630dfafab1246a7a3c901f59aa2065f.png
[20210208115129856.png]: /images/20221119/76e91694096843558004d0d8c44bb16a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221119/5202fb325fae45049b58fac53692dab9.png
[20210208115202473.png]: /images/20221119/ef56d11d63754b569eca1e961b499431.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221119/4d0499eda8e3417ab78f32f78f7c9951.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20221119/ee6c3dc782ea475ea67ab7164711c377.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]: /images/20221119/9ee3f48f4af4488d9fa01af10b10d469.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]: /images/20221119/e8ecc72b721e4adf85ca9ffb129c526e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]: /images/20221119/3f017330f5a64015a3bf078f16cd2270.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]: /images/20221119/c736e5583ba24f5fa80503f32d7fd106.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]: /images/20221119/fad71ef5cd714cc4a1afa27b97bab050.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 8]: /images/20221119/56c84ecdbdfe4670ae578742752f8309.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 9]: /images/20221119/835a60575d8d4e199b1cfa11fa98174e.png
[20210208120935891.png]: /images/20221119/e8014699e3ff40ac9e1621234feb4813.png
[20210220145541199.png]: /images/20221119/99a6c1403ff049ffb8cd711d8ff55eab.png
[20210208121139857.png]: /images/20221119/3b5eccf68aae42adafe325f75e01194f.png
[20210208121104542.png]: /images/20221119/5566320c01334d2b91c964523d6e90a4.png
[20210208121123670.png]: /images/20221119/0e0111d62a33407d825782290a710271.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 10]: /images/20221119/363cd1c84bd34b29ac61da64e620923b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 11]: /images/20221119/491a420f48ed45458e81abefa2378dc6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 12]: /images/20221119/e1190cc77573481c9e43907c30f1e7d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 13]: /images/20221119/4be7a1058e014f07b51c8f843f46c582.png
[20210208121646644.png]: https://img-blog.csdnimg.cn/20210208121646644.png
[20210220145647170.png]: https://img-blog.csdnimg.cn/20210220145647170.png
[20210220145714447.png]: https://img-blog.csdnimg.cn/20210220145714447.png
[20210220145738825.png]: https://img-blog.csdnimg.cn/20210220145738825.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 14]: https://img-blog.csdnimg.cn/20210208112815637.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 15]: https://img-blog.csdnimg.cn/20210208112930194.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg==,size_16,color_FFFFFF,t_70
[https_www.zhihu.com_search_type_content_q_git_E5_AD_A6_E4_B9_A0]: https://www.zhihu.com/search?type=content&q=git%E5%AD%A6%E4%B9%A0