前言

今天给大家分享一下，如何在公司里面去提交代码。提交代码一般是通过MR或者PR实现的。

在我们开发中，一般都是通过git管理代码，

我们去开发一个新的特性时:一般需要这样做：

1. 从主分支(master)上面拉一个新的分支(checkout)
2. 在这个新的分支开发新特性
3. 提交MR/PR 合并到主分支

这里面的三件事，都有很多规范在的。

例如：

1. 如何命名新的分支？
2. commit如何组织
3. PR/MR 如何创建？如何命名？message怎么写？

这些规范也是很重要的，遵循了这些规范，别人在review你的代码时才能更轻松。

首先我这里准备了我的GitHub账号，用于模拟协作开发的情景：

首先我初始化一个springboot项目，用于初始化仓库：

我们先将项目通过gitclone命令拉到本地：

目前项目属于master分支，根据规范，不允许直接push到master分支！！！

接下来我介绍一下关于分支的一些注意事项：

如何命名新的分支

首先，最重要的一点，遵循你们组所在的规范！！

因为这个东西没有一个非常统一的说法，本着入乡随俗的原则，如果你们组有这个规范，就遵循这个。

那么怎么看有没有呢？直接去看git信息！

例如：

你会发现他的开发分支都叫做develop，发布分支都叫做release-xx 后面是版本号。

一般来说，git分支的命名规范遵循这样的：

1. 功能分支: feature/xxxx 主要是开发新的特性时。
2. 发布分支: release/xxxx 用于发布某个版本。
3. bugfix分支: bugfix/xxx 用于修复某个bug。

除了这三种，还有其他的，例如上面的develop分支，master分支。。。。

那么接下来我创建一个分支，写一下代码：

由于IDEA内置一些git命令，我比较喜欢直接使用：

输入分支名并创建：

可以看到，新分支已经创建起来了：

接下来我们写一些代码，并提交commit

如何提交Commit

对于commit，有两个基本的原则：

• 原子的：每个commit只做一件事，减少review的复杂度。
• 描述清楚：comment里面清晰描述到底做了什么，不要使用一些模糊的语言。

对于描述信息怎么写，有个规范，基本大家都在遵循：

如何规范你的Git commit？-阿里云开发者社区

其中就提到了：

例如：

 git commit -m "feat: support springboot3" 

这里我简单输出一行代码并commit(IDEA快捷键Ctrl+K)一下：

再次查看一下git记录：

发现已经提交上了，接下来我们将它push到远程仓库(IDEA快捷键Ctrl+shift+k)：

我们登录GitHub查看刚才提交的代码：

可以看到，我之前创建的分支和写的代码均已提交，接下来我们进行pr也就是分支合并

如何创建PR/MR

如果你前面的规范遵循了，那么PR其实也就比较简单了。

创建PR一般需要填写这两部分内容：

Title: 简单描述PR干了什么？

Message: 如果PR表简洁，Title已经足够，这里可以空白；如果是有多个特性/修复。这里可以描述一下。

申请合并已经提交，这里需要其他人来确认合并：

合并成功，这样一个总流程已经做好了：

那么现在有一个问题，feature分支的代码已经合并到主分支里面了，本地主分支代码还是未合并的，应该怎么做呢？有一个很简单的办法，那就是将代码再拉一遍：

可以看到，本地master分支的代码已经更新，可以继续创建新的分支进行代码编写：

---

总结

在团队协作开发中，规范的代码提交流程是保障项目质量、提升协作效率的核心环节。通过本文的实践演示，我们可以将代码提交的完整规范与流程总结如下：

1. 分支管理
   按功能类型命名分支：feature/功能名（新特性）、bugfix/问题名（修复）、release/版本号（发布），禁止直接提交至master主分支。

2. Commit提交
   遵循"原子性+清晰描述"原则：每个提交只做一件事，用类型: 描述格式（如feat: 新增登录验证），避免模糊表述。

3. PR/MR合并
   标题简洁概括变更内容，复杂修改需补充说明；经团队审核后合并，合并后及时拉取主分支最新代码同步本地。

核心目标：通过规范降低协作成本，提升代码可维护性与质量。