diff --git a/docs/合并请求/代码评审.md b/docs/合并请求/代码评审.md index 24767fc..9b4aefb 100644 --- a/docs/合并请求/代码评审.md +++ b/docs/合并请求/代码评审.md @@ -1,4 +1,6 @@ --- sidebar_label: '代码评审' sidebar_position: 3 ---- \ No newline at end of file +--- + +# 代码评审 \ No newline at end of file diff --git a/docs/合并请求/创建合并请求.md b/docs/合并请求/创建合并请求.md index d20bf88..fae929e 100644 --- a/docs/合并请求/创建合并请求.md +++ b/docs/合并请求/创建合并请求.md @@ -1,4 +1,22 @@ --- sidebar_label: '创建合并请求' sidebar_position: 2 ---- \ No newline at end of file +--- + +# 创建合并请求 + +1. 进入需要发起合并请求的项目的“**合并请求(PR)**”界面，点击上方的“**新建合并请求**”按钮后，进入合并请求发布界面，如下所示： + +![合并请求模块](/static/img/PR/imagePR2.png) + +![合并请求发布界面](/static/img/PR/imagePR3.png) + +2. 选择需要合并的**源分支**和**目标分支**，其中源分支为已完成代码开发、需要合并其代码变更的分支，目标分支为要并入代码变更的分支，既可以是同一仓库下的其他分支（branch），也可以是被复刻的源仓库下的分支； + +3. 选中分支后，填写本次合并请求的标题和描述内容，为审查者提供辅助理解本次合并请求的信息，进而加快合并请求审查过程（见 ***代码评审*** 一节）； + +4. 此外，用户还可以在右侧边栏中指定审查人员、添加里程碑、标记以及优先级（合并请求本质上是一个疑修，这些操作与疑修模块中的操作含义相同或相近，所以可以参照疑修章节中的介绍辅助理解）； + +5. 最后信息填写完毕后，点击底部的“**创建**”按钮即可提交您的第一个合并请求了🎉🎉🎉！ + +![创建合并请求](/static/img/PR/imagePR4.png) \ No newline at end of file diff --git a/docs/合并请求/合并模式简介.md b/docs/合并请求/合并模式简介.md index d735120..5e17abe 100644 --- a/docs/合并请求/合并模式简介.md +++ b/docs/合并请求/合并模式简介.md @@ -1,4 +1,100 @@ --- sidebar_label: '合并模式简介' sidebar_position: 4 ---- \ No newline at end of file +--- + +# 合并模式简介 + +在审阅人审查完开发者提交的代码变更后，便可以决定是否将这些提交合并进主分支`master`中。 + +然而，对于不同分支间的提交合并，存在多种合并模式，下图为GitLink中支持的合并模式，包括**合并请求**、**变基并合并**、**变基合并 --no-ff**以及**压缩提交并合并**四种。 + +![合并模式](/static/img/PR/imagePR5.png) + +1. **合并请求** + +**合并请求**是最常用的合并模式，以下图为例，开发者在主分支`master`的提交3处拉取了开发分支`dev`，然后分别提交了A、B、C，然后在`master`分支上进行合并。 + +快进合并前： + +![快进合并前](/static/img/PR/imagePR6.png) + +快进合并后： + +![快进合并后](/static/img/PR/imagePR7.png) + +**注意**：可以看到，合并的过程就是直接把`master`指针移动到了`dev`指针处，这种合并被称为**快进（fast-forward）**，之所以出现这种情形是因为在提交3之后，`master`分支上没有新的提交，所以通过直接快进`master`指针就可以完成合并；但如果在`master`分支上也有新的提交，就需要进行实质性的合并了，如下面两幅图所示： + +在合并前，`dev`分支上提交A之后、提交B之前，`master`分支上提交了4，这时合并`dev`分支就不能简单地快进移动，而是要比较两个分支上更改的内容，然后进行合并； + +非快进合并前： + +![非快进合并前](/static/img/PR/imagePR8.png) + + +合并之后，提交A、B、C都会按时间线加入`master`的提交记录中，并且会生成一个新的提交D，用于记录合并这件事情；此外，如果合并过程中发生了冲突，即两个分支对同一个文件进行了修改，则需要手动处理冲突；这种合并方式就是**非快进（no fast-forward）**，这也是**合并请求**模式下的默认方式！ + +非快进合并后： + +![非快进合并后](/static/img/PR/imagePR9.png) + +为了方便理解，可以以线性方式查看合并后的`master`分支上的提交记录 + +![线性的提交记录](/static/img/PR/imagePR10.png) + +**总结**：在**合并请求**模式下，默认采用**非快进**合并开发分支到`master`分支上，而**非快进**方式会生成一个特殊的提交用于记录此次合并事件！ + +2. **变基并合并** + +从**合并请求**后`master`分支上的提交记录可以看出，两个分支的提交记录可能会交叉在一起，这可能会给后续开发带来困扰，而**变基并合并**可以解决这个问题。 + +**变基并合并**包括两个操作：**变基**、**合并**。首先是变基，以下图为例，`dev`分支是从提交3处拉取出来的，所以提交3就是`dev`的基，而变基操作就是改变`dev`的基，使其变为`master`分支上最新的一次提交。当然，变基过程中可能会出现冲突，则需要手动处理。 + +变基前： + +![变基前](/static/img/PR/imagePR8.png) + +变基后、合并前： + +![变基后_合并前](/static/img/PR/imagePR11.png) + + +`dev`分支变基之后，`master`分支就没有“更新”的提交了，所以此时进行合并，就得到了如下的结果 + +合并后： + +![合并后](/static/img/PR/imagePR12.png) + +**总结**：在**变基并合并**模式下，开发分支`dev`可以先进行变基操作，使其上的提交看起来都是在`master`分支最新的提交基础上进行的，然后再通过**快进**方式合并回`master`分支，从而起到整理提交记录的作用！ + +3. **变基合并 --no-ff** + +因为**变基并合并**进行合并操作时，默认采用**快进**方式，这样在`master`分支上就没有一个特殊的提交用于记录这次合并事件，所以可以使用`--no-ff`（**no fast-forward**）选项申明采用**非快进**方式进行合并。 + +`--no-ff`合并前： + +![--no-ff合并前](/static/img/PR/imagePR11.png) + +`--no-ff`合并后： + +![--no-ff合并后](/static/img/PR/imagePR13.png) + +**总结**：通过`--no-ff`选项，可以显式声明在合并时采用**非快进**方式，这样就可以在`master`分支中添加一个记录合并事件的提交！ + +4. **压缩提交并合并** + +在`dev`或者`feature`这样的开发分支中，开发者为了完成某个需求会进行多次提交，然而这些琐碎的提交信息在合并回`master`分支后，会使`master`上的提交记录臃肿混乱，所以需要在合并前，对这些提交进行压缩。如图所示，压缩操作是在`master`分支上进行的，本质是将`dev`分支上进行的变更施加到`master`分支维护的文件上，然后将这些修改用新的提交5保存，最后提交。 + +压缩前： + +![压缩前](/static/img/PR/imagePR8.png) + +压缩后、提交前： + +![压缩后_提交前](/static/img/PR/imagePR14.png) + +提交后： + +![提交后](/static/img/PR/imagePR15.png) + +**总结**：在合并前，先对开发分支上的琐碎提交进行压缩，可以使`master`分支上的提交信息更简洁，但是要注意，这种合并模式本质上是`master`分支一次性保存`dev`上的变更，并创建新的提交记录这些变更，所以提交者发生了变化！ \ No newline at end of file diff --git a/docs/合并请求/合并请求关联疑修.md b/docs/合并请求/合并请求关联疑修.md index 575cead..ac29313 100644 --- a/docs/合并请求/合并请求关联疑修.md +++ b/docs/合并请求/合并请求关联疑修.md @@ -1,4 +1,6 @@ --- sidebar_label: '合并请求关联疑修' sidebar_position: 5 ---- \ No newline at end of file +--- + +# 合并请求关联疑修 \ No newline at end of file diff --git a/docs/合并请求/合并请求简介.md b/docs/合并请求/合并请求简介.md index f6ceb0d..4142c04 100644 --- a/docs/合并请求/合并请求简介.md +++ b/docs/合并请求/合并请求简介.md @@ -1,4 +1,16 @@ --- sidebar_label: '合并请求简介' sidebar_position: 1 ---- \ No newline at end of file +--- + +# 合并请求简介 + +**合并请求(PR)** 模块提供合并请求创建和管理两方面的功能： + +- 一方面支持向源项目或者同一个项目其他分支创建（发起）代码合并请求（Pull Request，PR）； + +- 另一方面也为项目管理者对他人发送到本项目的合并请求进行管理、审阅并最终确定是否纳入项目。 + +如下图所示为合并请求(PR)管理模块： + +![合并请求管理模块](/static/img/PR/imagePR1.png) \ No newline at end of file diff --git a/static/img/PR/imagePR1.png b/static/img/PR/imagePR1.png new file mode 100644 index 0000000..48a38b8 Binary files /dev/null and b/static/img/PR/imagePR1.png differ diff --git a/static/img/PR/imagePR10.png b/static/img/PR/imagePR10.png new file mode 100644 index 0000000..95c83de Binary files /dev/null and b/static/img/PR/imagePR10.png differ diff --git a/static/img/PR/imagePR11.png b/static/img/PR/imagePR11.png new file mode 100644 index 0000000..b69b43f Binary files /dev/null and b/static/img/PR/imagePR11.png differ diff --git a/static/img/PR/imagePR12.png b/static/img/PR/imagePR12.png new file mode 100644 index 0000000..03762cc Binary files /dev/null and b/static/img/PR/imagePR12.png differ diff --git a/static/img/PR/imagePR13.png b/static/img/PR/imagePR13.png new file mode 100644 index 0000000..1de38d0 Binary files /dev/null and b/static/img/PR/imagePR13.png differ diff --git a/static/img/PR/imagePR14.png b/static/img/PR/imagePR14.png new file mode 100644 index 0000000..f8a2ae7 Binary files /dev/null and b/static/img/PR/imagePR14.png differ diff --git a/static/img/PR/imagePR15.png b/static/img/PR/imagePR15.png new file mode 100644 index 0000000..445b8e0 Binary files /dev/null and b/static/img/PR/imagePR15.png differ diff --git a/static/img/PR/imagePR2.png b/static/img/PR/imagePR2.png new file mode 100644 index 0000000..5ff7705 Binary files /dev/null and b/static/img/PR/imagePR2.png differ diff --git a/static/img/PR/imagePR3.png b/static/img/PR/imagePR3.png new file mode 100644 index 0000000..7b57eae Binary files /dev/null and b/static/img/PR/imagePR3.png differ diff --git a/static/img/PR/imagePR4.png b/static/img/PR/imagePR4.png new file mode 100644 index 0000000..4c40359 Binary files /dev/null and b/static/img/PR/imagePR4.png differ diff --git a/static/img/PR/imagePR5.png b/static/img/PR/imagePR5.png new file mode 100644 index 0000000..eee1815 Binary files /dev/null and b/static/img/PR/imagePR5.png differ diff --git a/static/img/PR/imagePR6.png b/static/img/PR/imagePR6.png new file mode 100644 index 0000000..b0f9d27 Binary files /dev/null and b/static/img/PR/imagePR6.png differ diff --git a/static/img/PR/imagePR7.png b/static/img/PR/imagePR7.png new file mode 100644 index 0000000..b9f1ffb Binary files /dev/null and b/static/img/PR/imagePR7.png differ diff --git a/static/img/PR/imagePR8.png b/static/img/PR/imagePR8.png new file mode 100644 index 0000000..880b36d Binary files /dev/null and b/static/img/PR/imagePR8.png differ diff --git a/static/img/PR/imagePR9.png b/static/img/PR/imagePR9.png new file mode 100644 index 0000000..982e98c Binary files /dev/null and b/static/img/PR/imagePR9.png differ