Git代码提交规范
Git代码提交规范
- 团队协作模式
-
- 1. 分支模式
- 2. fork模式
- fork模式开发实例
- 1. fork
- 2. 本地仓、远程仓、主仓
-
- 2.1 远程仓
- 2.2 本地仓
- 2.3 主仓
- 3. Issues
- 4. 提交代码
- 5. 提交MR
- 6. 合入
- 7. 不符合规范重新提交
-
- 7.1 撤销代码
上一章我们讲解了如何Fork代码仓并提交PR代码
但是有的同学就问了，那如何规范的提交代码呢？提交信息和整个流程是怎么样的呢？
这里我们一起探讨一下工作过程中如何规范git提交代码。
这里面我们所有的操作都以代码仓Git试验田为主仓进行操作。
大家先行fork，并拉取代码到本地吧。
团队协作模式
这里我们先来讲一下目前比较流行的两种代码仓管理模式。
1. 分支模式
顾名思义就是以每个人的分支名做提交开发，比如主master、dev，然后从dev分支切出一个自己的分支为jack，以后都是在自己的分支开发，然后合并到dev分支。此模式适合人不多的小型公司，分支不多好管理。具体不展开讨论，后期专门写一篇文章讲解吧。
2. fork模式
这个是今天的主角，适合人多的团队协作，不用建这么多的分支。具体的流程是主的master可以设置为保护分支，然后主要开发还是在dev分支，大家都fork dev分支到自己的仓库，开发完成提交到自己仓库的dev分支或其他分支，然后提交MR，请求合入上游dev分支，具体的流程图如下图：
fork模式开发实例
有了上面的基础fork模型，我们就可以根据理论进行实践了。
详细的可以参考https://jackwei.blog.csdn.net/article/details/127661721
1. fork
首先我们先从公司主仓fork一份到自己的远程代码仓。
https://gitee.com/jackwei1996/gitdemo
2. 本地仓、远程仓、主仓
2.1 远程仓
远程仓就是在云上自己fork下来的仓库。
首先到自己的远程仓库，点击克隆，复制链接。
2.2 本地仓
本地仓就是本地计算机拉下来的代码。
这里我们以VSCode为例：
打开Terminal，然后克隆刚才复制的链接。
# 进入你要存储代码的位置
cd E:\
cd code
# 拉取代码
git clone https://gitee.com/jackwei1996/gitdemo.git
然后打开刚才下载好的文件夹
2.3 主仓
主仓就是公司主代码仓库了，就是我们fork的对象仓库。
这个是用来同步代码的，比如别的同事开发完会合入公司主仓，我们需要同步下来代码继续开发。
这时需要手动添加一下：
git remote add upstream https://gitee.com/jack0240/gitdemo.git
这里一定要注意，origin是你自己的远程代码仓，upstream是上游仓也就是你公司的主仓。
拉取上游仓代码命令在写代码之前，一定要先拉取一下，避免冲突：
git pull upstream master
3. Issues
有需求才有提交，在开发之前我们得新建一个Issues。
注意这里我们是在公司的主仓提Issues，不要在自己仓库提！！！
标题的前缀可选：【需求】、【bug】、【优化】、【测试】
然后在详情里面越详细描述越好，建议多上传图片，如果涉及到bug，将错误信息不要吝啬的贴上去。
4. 提交代码
有了Issues就有了目标，有了目标就可以详细开发了。
这里我们新建了一个mr.log文件，里面写了一些内容。
然后，首先提交到自己的分支。
这里就需要注意了，一般我们是要有提交规范的，这里需要讲解一下。
- 必须有前缀：【需求开发】、【bug修复】、【重构优化】、【测试】
然后就是标题（概括修改）。
如果本地提交改动比较多，逻辑比较复杂，还需要添加【修改内容】描述本次修改的重点、难点、需要注意的协同等。 - 一次提交不要超过1000行增加
- 一个文件不要超过1000行代码
- 一个方法不要超过100行
- 请遵守开发手册规范
这里我们点击提交，如果出现下面提示，说明没有配置全局用户名和邮箱。
git config --global user.name "Jack"
git config --global user.email [email protected]
上面的提交只是提交到本地，
还有一步需要提交到自己远程仓库。
他会询问你提交远程的代码仓库分支，默认是设置的分支。
如果没有登录需要登录一下：
5. 提交MR
上面的操作之后就可以看到自己的远程仓已经有提交记录了。
这个时候我们需要合入公司的主仓了：
新建的标题和提交标题保持一致就行，下面有提交记录，可以复制。
下面的描述就是详细填写修改内容，复杂的业务流程需要详细说明，便于后期Review。
注意这里的审查人员和测试，需要选对人！！！
如果忘记填写优先级、标签、关联Issue，可以创建后修改。
6. 合入
这个时候主仓就会看到你提交的MR请求，会有对应的测试人员和Committer进行测试和代码Review。
到这里整个流程就已经走通了，但是如果不幸运的话会被打回去重新修改代码。
7. 不符合规范重新提交
由于代码书写不规范，提交MR也不规范，这时候需要打回去重新修改。
7.1 撤销代码
这个时候我们要回退上一次提交代码。
git reset HEAD~1
按要求规范修改，然后保存Commit。
这个时候我们不能再去点Sync了，因为我们知道改了同一个文件，还没合入再次提交肯定冲突。
这个时候我们需要强制提交：
git push origin master -f
这个时候就可以继续审核代码等待合入即可。
到这里就全部讲解完成了，欢迎大家加入开源的世界，一起创造未来~