From 341c4db025339198a1121ee6864aa06ca15d1562 Mon Sep 17 00:00:00 2001
From: zzzzzyh <2818067902@qq.com>
Date: Thu, 29 May 2025 14:42:50 +0800
Subject: [PATCH] =?UTF-8?q?=E5=90=88=E5=B9=B6=E9=83=A8=E5=88=86=E4=B8=AD?=
=?UTF-8?q?=E5=9B=BE=E7=89=87=E8=B7=AF=E5=BE=84=E9=97=AE=E9=A2=98?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
docs/合并请求/合并模式简介.md | 28 +++++++++----------
docs/合并请求/合并请求简介.md | 2 +-
.../代码库管理/代码提交.md | 24 +++++++++++++++-
3 files changed, 38 insertions(+), 16 deletions(-)
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**以及**压缩提交并合并**四种。
-
+
1. **合并请求**
@@ -17,11 +17,11 @@ sidebar_position: 4
快进合并前：
-
+
快进合并后：
-
+
**注意**：可以看到，合并的过程就是直接把`master`指针移动到了`dev`指针处，这种合并被称为**快进（fast-forward）**，之所以出现这种情形是因为在提交3之后，`master`分支上没有新的提交，所以通过直接快进`master`指针就可以完成合并；但如果在`master`分支上也有新的提交，就需要进行实质性的合并了，如下面两幅图所示：
@@ -29,18 +29,18 @@ sidebar_position: 4
非快进合并前：
-
+
合并之后，提交A、B、C都会按时间线加入`master`的提交记录中，并且会生成一个新的提交D，用于记录合并这件事情；此外，如果合并过程中发生了冲突，即两个分支对同一个文件进行了修改，则需要手动处理冲突；这种合并方式就是**非快进（no fast-forward）**，这也是**合并请求**模式下的默认方式！
非快进合并后：
-
+
为了方便理解，可以以线性方式查看合并后的`master`分支上的提交记录
-
+
**总结**：在**合并请求**模式下，默认采用**非快进**合并开发分支到`master`分支上，而**非快进**方式会生成一个特殊的提交用于记录此次合并事件！
@@ -52,18 +52,18 @@ sidebar_position: 4
变基前：
-
+
变基后、合并前：
-
+
`dev`分支变基之后，`master`分支就没有“更新”的提交了，所以此时进行合并，就得到了如下的结果
合并后：
-
+
**总结**：在**变基并合并**模式下，开发分支`dev`可以先进行变基操作，使其上的提交看起来都是在`master`分支最新的提交基础上进行的，然后再通过**快进**方式合并回`master`分支，从而起到整理提交记录的作用！
@@ -73,11 +73,11 @@ sidebar_position: 4
`--no-ff`合并前：
-
+
`--no-ff`合并后：
-
+
**总结**：通过`--no-ff`选项，可以显式声明在合并时采用**非快进**方式，这样就可以在`master`分支中添加一个记录合并事件的提交！
@@ -87,14 +87,14 @@ sidebar_position: 4
压缩前：
-
+
压缩后、提交前：
-
+
提交后：
-
+
**总结**：在合并前，先对开发分支上的琐碎提交进行压缩，可以使`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)管理模块：
-
\ No newline at end of file
+
\ 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. 代码提交入口**
+在仓库主页，点击"代码"标签页，即可进入代码提交模块，如下图所示。
+
+
+### **2. 编辑代码**
+点击文件右侧的编辑按钮，开始编辑代码。
+
+
+### **3. 提交变更**
+在编辑框中编写代码，编写完成后填写变更信息（包括提交说明和分支选择），点击"提交变更"按钮即可完成代码提交。
+
+
+### **4. 提交成功**
+提交成功后，代码将更新到选定的分支中，并显示最新的提交记录。
+
+
+### **5. 提交历史**
+在代码提交模块中，可以查看所有分支的提交历史记录，包括提交者、提交时间、提交说明等信息。
+
\ No newline at end of file