From c512ac1e17d7b0b3d6a83993fd738682dd4ce7a9 Mon Sep 17 00:00:00 2001 From: zhouhuaian Date: Mon, 5 Jun 2023 14:38:16 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E5=9B=BE=E7=89=87=E6=96=87?= =?UTF-8?q?=E4=BB=B6=E8=B7=AF=E5=BE=84=E9=94=99=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/合并请求/创建合并请求.md | 6 +++--- docs/合并请求/合并模式简介.md | 28 ++++++++++++------------- docs/合并请求/合并请求简介.md | 2 +- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/合并请求/创建合并请求.md b/docs/合并请求/创建合并请求.md index fae929e..ce7059e 100644 --- a/docs/合并请求/创建合并请求.md +++ b/docs/合并请求/创建合并请求.md @@ -7,9 +7,9 @@ sidebar_position: 2 1. 进入需要发起合并请求的项目的“**合并请求(PR)**”界面，点击上方的“**新建合并请求**”按钮后，进入合并请求发布界面，如下所示： -![合并请求模块](/static/img/PR/imagePR2.png) +![合并请求模块](/img/PR/imagePR2.png) -![合并请求发布界面](/static/img/PR/imagePR3.png) +![合并请求发布界面](/img/PR/imagePR3.png) 2. 选择需要合并的**源分支**和**目标分支**，其中源分支为已完成代码开发、需要合并其代码变更的分支，目标分支为要并入代码变更的分支，既可以是同一仓库下的其他分支（branch），也可以是被复刻的源仓库下的分支； @@ -19,4 +19,4 @@ sidebar_position: 2 5. 最后信息填写完毕后，点击底部的“**创建**”按钮即可提交您的第一个合并请求了🎉🎉🎉！ -![创建合并请求](/static/img/PR/imagePR4.png) \ No newline at end of file +![创建合并请求](/img/PR/imagePR4.png) \ No newline at end of file diff --git a/docs/合并请求/合并模式简介.md b/docs/合并请求/合并模式简介.md index 5e17abe..c8d0750 100644 --- a/docs/合并请求/合并模式简介.md +++ b/docs/合并请求/合并模式简介.md @@ -9,7 +9,7 @@ sidebar_position: 4 然而，对于不同分支间的提交合并，存在多种合并模式，下图为GitLink中支持的合并模式，包括**合并请求**、**变基并合并**、**变基合并 --no-ff**以及**压缩提交并合并**四种。 -![合并模式](/static/img/PR/imagePR5.png) +![合并模式](/img/PR/imagePR5.png) 1. **合并请求** @@ -17,11 +17,11 @@ sidebar_position: 4 快进合并前： -![快进合并前](/static/img/PR/imagePR6.png) +![快进合并前](/img/PR/imagePR6.png) 快进合并后： -![快进合并后](/static/img/PR/imagePR7.png) +![快进合并后](/img/PR/imagePR7.png) **注意**：可以看到，合并的过程就是直接把`master`指针移动到了`dev`指针处，这种合并被称为**快进（fast-forward）**，之所以出现这种情形是因为在提交3之后，`master`分支上没有新的提交，所以通过直接快进`master`指针就可以完成合并；但如果在`master`分支上也有新的提交，就需要进行实质性的合并了，如下面两幅图所示： @@ -29,18 +29,18 @@ sidebar_position: 4 非快进合并前： -![非快进合并前](/static/img/PR/imagePR8.png) +![非快进合并前](/img/PR/imagePR8.png) 合并之后，提交A、B、C都会按时间线加入`master`的提交记录中，并且会生成一个新的提交D，用于记录合并这件事情；此外，如果合并过程中发生了冲突，即两个分支对同一个文件进行了修改，则需要手动处理冲突；这种合并方式就是**非快进（no fast-forward）**，这也是**合并请求**模式下的默认方式！ 非快进合并后： -![非快进合并后](/static/img/PR/imagePR9.png) +![非快进合并后](/img/PR/imagePR9.png) 为了方便理解，可以以线性方式查看合并后的`master`分支上的提交记录 -![线性的提交记录](/static/img/PR/imagePR10.png) +![线性的提交记录](/img/PR/imagePR10.png) **总结**：在**合并请求**模式下，默认采用**非快进**合并开发分支到`master`分支上，而**非快进**方式会生成一个特殊的提交用于记录此次合并事件！ @@ -52,18 +52,18 @@ sidebar_position: 4 变基前： -![变基前](/static/img/PR/imagePR8.png) +![变基前](/img/PR/imagePR8.png) 变基后、合并前： -![变基后_合并前](/static/img/PR/imagePR11.png) +![变基后_合并前](/img/PR/imagePR11.png) `dev`分支变基之后，`master`分支就没有“更新”的提交了，所以此时进行合并，就得到了如下的结果 合并后： -![合并后](/static/img/PR/imagePR12.png) +![合并后](/img/PR/imagePR12.png) **总结**：在**变基并合并**模式下，开发分支`dev`可以先进行变基操作，使其上的提交看起来都是在`master`分支最新的提交基础上进行的，然后再通过**快进**方式合并回`master`分支，从而起到整理提交记录的作用！ @@ -73,11 +73,11 @@ sidebar_position: 4 `--no-ff`合并前： -![--no-ff合并前](/static/img/PR/imagePR11.png) +![--no-ff合并前](/img/PR/imagePR11.png) `--no-ff`合并后： -![--no-ff合并后](/static/img/PR/imagePR13.png) +![--no-ff合并后](/img/PR/imagePR13.png) **总结**：通过`--no-ff`选项，可以显式声明在合并时采用**非快进**方式，这样就可以在`master`分支中添加一个记录合并事件的提交！ @@ -87,14 +87,14 @@ sidebar_position: 4 压缩前： -![压缩前](/static/img/PR/imagePR8.png) +![压缩前](/img/PR/imagePR8.png) 压缩后、提交前： -![压缩后_提交前](/static/img/PR/imagePR14.png) +![压缩后_提交前](/img/PR/imagePR14.png) 提交后： -![提交后](/static/img/PR/imagePR15.png) +![提交后](/img/PR/imagePR15.png) **总结**：在合并前，先对开发分支上的琐碎提交进行压缩，可以使`master`分支上的提交信息更简洁，但是要注意，这种合并模式本质上是`master`分支一次性保存`dev`上的变更，并创建新的提交记录这些变更，所以提交者发生了变化！ \ No newline at end of file diff --git a/docs/合并请求/合并请求简介.md b/docs/合并请求/合并请求简介.md index 4142c04..c0ac142 100644 --- a/docs/合并请求/合并请求简介.md +++ b/docs/合并请求/合并请求简介.md @@ -13,4 +13,4 @@ sidebar_position: 1 如下图所示为合并请求(PR)管理模块： -![合并请求管理模块](/static/img/PR/imagePR1.png) \ No newline at end of file +![合并请求管理模块](/img/PR/imagePR1.png) \ No newline at end of file