diff --git a/docs/合并请求/合并模式简介.md b/docs/合并请求/合并模式简介.md index c8d0750..8effb42 100644 --- a/docs/合并请求/合并模式简介.md +++ b/docs/合并请求/合并模式简介.md @@ -9,7 +9,7 @@ sidebar_position: 4 然而,对于不同分支间的提交合并,存在多种合并模式,下图为GitLink中支持的合并模式,包括**合并请求**、**变基并合并**、**变基合并 --no-ff**以及**压缩提交并合并**四种。 -![合并模式](/img/PR/imagePR5.png) +![合并模式](../../static/img/PR/imagePR5.png) 1. **合并请求** @@ -17,11 +17,11 @@ sidebar_position: 4 快进合并前: -![快进合并前](/img/PR/imagePR6.png) +![快进合并前](../../static/img/PR/imagePR6.png) 快进合并后: -![快进合并后](/img/PR/imagePR7.png) +![快进合并后](../../static/img/PR/imagePR7.png) **注意**:可以看到,合并的过程就是直接把`master`指针移动到了`dev`指针处,这种合并被称为**快进(fast-forward)**,之所以出现这种情形是因为在提交3之后,`master`分支上没有新的提交,所以通过直接快进`master`指针就可以完成合并;但如果在`master`分支上也有新的提交,就需要进行实质性的合并了,如下面两幅图所示: @@ -29,18 +29,18 @@ sidebar_position: 4 非快进合并前: -![非快进合并前](/img/PR/imagePR8.png) +![非快进合并前](../../static/img/PR/imagePR8.png) 合并之后,提交A、B、C都会按时间线加入`master`的提交记录中,并且会生成一个新的提交D,用于记录合并这件事情;此外,如果合并过程中发生了冲突,即两个分支对同一个文件进行了修改,则需要手动处理冲突;这种合并方式就是**非快进(no fast-forward)**,这也是**合并请求**模式下的默认方式! 非快进合并后: -![非快进合并后](/img/PR/imagePR9.png) +![非快进合并后](../../static/img/PR/imagePR9.png) 为了方便理解,可以以线性方式查看合并后的`master`分支上的提交记录 -![线性的提交记录](/img/PR/imagePR10.png) +![线性的提交记录](../../static/img/PR/imagePR10.png) **总结**:在**合并请求**模式下,默认采用**非快进**合并开发分支到`master`分支上,而**非快进**方式会生成一个特殊的提交用于记录此次合并事件! @@ -52,18 +52,18 @@ sidebar_position: 4 变基前: -![变基前](/img/PR/imagePR8.png) +![变基前](../../static/img/PR/imagePR8.png) 变基后、合并前: -![变基后_合并前](/img/PR/imagePR11.png) +![变基后_合并前](../../static/img/PR/imagePR11.png) `dev`分支变基之后,`master`分支就没有“更新”的提交了,所以此时进行合并,就得到了如下的结果 合并后: -![合并后](/img/PR/imagePR12.png) +![合并后](../../static/img/PR/imagePR12.png) **总结**:在**变基并合并**模式下,开发分支`dev`可以先进行变基操作,使其上的提交看起来都是在`master`分支最新的提交基础上进行的,然后再通过**快进**方式合并回`master`分支,从而起到整理提交记录的作用! @@ -73,11 +73,11 @@ sidebar_position: 4 `--no-ff`合并前: -![--no-ff合并前](/img/PR/imagePR11.png) +![--no-ff合并前](../../static/img/PR/imagePR11.png) `--no-ff`合并后: -![--no-ff合并后](/img/PR/imagePR13.png) +![--no-ff合并后](../../static/img/PR/imagePR13.png) **总结**:通过`--no-ff`选项,可以显式声明在合并时采用**非快进**方式,这样就可以在`master`分支中添加一个记录合并事件的提交! @@ -87,14 +87,14 @@ sidebar_position: 4 压缩前: -![压缩前](/img/PR/imagePR8.png) +![压缩前](../../static/img/PR/imagePR8.png) 压缩后、提交前: -![压缩后_提交前](/img/PR/imagePR14.png) +![压缩后_提交前](../../static/img/PR/imagePR14.png) 提交后: -![提交后](/img/PR/imagePR15.png) +![提交后](../../static/img/PR/imagePR15.png) **总结**:在合并前,先对开发分支上的琐碎提交进行压缩,可以使`master`分支上的提交信息更简洁,但是要注意,这种合并模式本质上是`master`分支一次性保存`dev`上的变更,并创建新的提交记录这些变更,所以提交者发生了变化! \ No newline at end of file diff --git a/docs/合并请求/合并请求简介.md b/docs/合并请求/合并请求简介.md index 9bb4295..5b803f9 100644 --- a/docs/合并请求/合并请求简介.md +++ b/docs/合并请求/合并请求简介.md @@ -15,4 +15,4 @@ GitLink中的 **合并请求(PR)** 模块提供合并请求创建和管理两方 如下图所示为合并请求(PR)管理模块: -![合并请求管理模块](/img/PR/imagePR1.png) \ No newline at end of file +![合并请求管理模块](../../static/img/PR/imagePR1.png) \ No newline at end of file diff --git a/versioned_docs/version-1.1.0/代码库管理/代码提交.md b/versioned_docs/version-1.1.0/代码库管理/代码提交.md index 11b6835..8782071 100644 --- a/versioned_docs/version-1.1.0/代码库管理/代码提交.md +++ b/versioned_docs/version-1.1.0/代码库管理/代码提交.md @@ -1,4 +1,26 @@ --- sidebar_label: '代码提交' sidebar_position: 3 ---- \ No newline at end of file +--- + +# 代码提交 + +### **1. 代码提交入口** +在仓库主页,点击"代码"标签页,即可进入代码提交模块,如下图所示。 +![](../../../static/img/代码库管理/代码提交/代码提交入口.png)
+ +### **2. 编辑代码** +点击文件右侧的编辑按钮,开始编辑代码。 +![](../../../static/img/代码库管理/代码提交/编辑代码.png)
+ +### **3. 提交变更** +在编辑框中编写代码,编写完成后填写变更信息(包括提交说明和分支选择),点击"提交变更"按钮即可完成代码提交。 +![](../../../static/img/代码库管理/代码提交/提交变更.png)
+ +### **4. 提交成功** +提交成功后,代码将更新到选定的分支中,并显示最新的提交记录。 +![](../../../static/img/代码库管理/代码提交/提交成功.png)
+ +### **5. 提交历史** +在代码提交模块中,可以查看所有分支的提交历史记录,包括提交者、提交时间、提交说明等信息。 +![](../../../static/img/代码库管理/代码提交/提交历史.png)
\ No newline at end of file