脚注格式怎么设置成带圆圈数字(脚注格式怎么设置)

程序员必读：如何写出令人惊艳的代码提交注释?

#头条创作挑战赛#

终身学习、乐于分享、共同成长！

前言

写提交注释有什么用？

不知道你们公司是否会有提交代码PR的评审？我公司是针对一个SaaS产品进行迭代式开发的，当有一个新的迭代需求过来时，做完需求评审、开发设计评审后进入到开发流程：

建立迭代版本分支 → 开发同学基于迭代版本分支拉取自己的本地分支 → 开发编码 → 冒烟自测 → 提交PR到迭代版本分支 → 开发负责人评审 → 评审通过合并到版本分支

评审者评审代码时要做的工作主要有几方面：

了解本次PR代码变更的意图是否遵循基本的编码规范初步判断逻辑是否合理

如果一个PR中变更的文件非常多，同时又没有一些有效的提交注释来辅助评审者评审代码，那这个评审工作将会是灾难！

提交注释的作用

但如果你提交的代码中有很完整且非常有效详细的提交注释，那将可以帮助评审者快速地评审代码。

提交注释至少有几个方面的作用：

让评审者快速了解本次变更的意图可通过脚本生成变更日志（changelog）帮助评审者快速识别和过滤不重要的代码变更浏览变更历史时可快速得到更多有用的信息让评审者快速了解本次变更的意图

通过规范的描述，评审人可以快速掌握变更意图，并判断与实际变更内容是否相符。提升代码检视的有效性和工作效率。

可通过脚本生成变更日志（changelog）

在变更日志中使用以下三个部分：新功能，错误修复，重大更改。当发布时，该变更日志列表可以由脚本生成，以及相关提交的链接。

查看自上次发布以来，所有提交主题（提交消息中的第一行）的命令:

git log <last tag> HEAD --pretty=format:%s

当前发布中所有的新特性的 git 命令：

git log <last release> HEAD --grep feat

以我公司项目为例，首先查看自上次发布以来，所有提交主题（提交消息中的第一行）：

git log tcp-1.0.8 HEAD --pretty=format:%s

从上面的结果可以看出还是能拿到一些有用信息的，红色框框起来的关联任务ID能找到。

接着来查看当前发布中所有的新特性：

git log tcp-1.0.8 HEAD --grep feat

从结果来看，这个压根就找不到有哪些新特性的变更了，这些都是无效的提交注释。

识别或过滤不重要的代码变更

在平时写代码的时候我们的确都会提交一些不重要的代码变更，如一些代码格式的变更（添加/删除空格/空行，缩进），缺少分号，注释等。所以，在查找变更时，可以忽略这些提交——因为这些提交内容中没有代码逻辑的更改。

当使用二分法查找 （bisecting）时,你可以使用下面命令来忽略这些不重要的变更：

git bisect skip $(git rev-list --grep irrelevant <good place> HEAD)浏览变更历史时可快速得到更多有用的信息

如何做到让评审者能快速得到更多有用的信息呢？

这这就要求提交注释需要遵循一定的标准规则，可以增加更多的 “上下文”信息。

先看看让我们看看下面这些实际的提交注释（ bad example ）：

修复注释中的一个typo修复测试。Application - 应该移除旧的iframedocs - 多个文档链接的修改docs - 删除多余的空白行当从后台获取文本时，用单行空白代替双行空白。

这些信息都试图告诉我们代码变更到底发生在哪里，但它们都没有一致的共同约定.

所以，它们都不是好的注释。

再看一看下面的实际提交注释（bad example）：

修复失败单测模块信息更正防止内存泄漏搜索优化

你能一眼看出上面的每个提交中都改了什么吗？这些提交注释几乎没有提供有用信息，所以，也不是好的注释。我们当然可以可以查看被修改过的文件来找到具体信息，但是，这样会很慢。

以上的例子，都是因为缺少共同的约定。因此，我们订立如下格式约定。

提交注释的格式

提交注释格式如下所示。它由三个段落组成，分别是：主题行，内容体和脚注，并由一个空行分隔。

主题行

主题行只有一行，不可多行，且行尾不需要标点符号。

主题行占用一行，它是对本次代码变更的简洁描述，其包含类型<type>，作用域<scope>和主题内容。其中，作用域是可选项，如果产品项目组自身没有规定，也可以不写。

<type>类型如下：

revert（仅当revert之前的一个提交时使用）feat (当添加特性时使用)fix (当修改bug时使用)refector（在进行代码重构时使用）docs (当写文档时使用)test (当被测试用例时使用)style (在代码进行格式化，或添加必要的注释，或对文档补充标点符号等情况下使用，此时即不改变代码逻辑，也没对文档添加实质性内容）

type 是必填项，且只选其一。

上面的类型列表中，权重由高到低排列。

当且仅当一次 MR ( 或 PR )中包含多个类型时，须选择权重高的类型使用。

<scope>的取值

Scope 可以是指代本次代码变更的具置或模块。其内容可以由产品项目组指定。例如，在新闻 App 中，可能的scope是 日历/评论/上报/视频/TAB 等。

scope是非必填项。

当包含Scope时，其应该使用半角符号 ( 和 ) 包围，并在Scope前加入半角符号$。

<subject>的文本书写方式

它用于对变更的简短描述。

主题行应使用祈使句式和现在时。 “ change ” not “ changed ” nor “ changes ”句首是英文单词时，首字母要大写。句末不要有标点符号它与行前内容之间，使用一个半角冒号和一个半角空格隔开。内容体

内容体用于解释修改动机和修改内容，可以由多行组成。

内容体的书写要求

内容体也应该用祈使句式和现在时。

由于主题的字数限制，可能无法完整讲清楚本次变更的动机，与之前程序逻辑的不同之处，以及一些技术细节。所以，可以在“内容体”里加入更多的说明。

内容体应该采用完整且简洁的描述来：

说明变更的目的解释变更的机理对于与性能相关的变更，要提供基准信息。

检验标准是：评审者必须能够在不熟悉上下文的情况下，通过这段描述对代码进行有效评审，否则，评审者可直接打回要求重新提交。

内容体中建议包含“ TestPlan ” 段落。

TestPlan

TestPlan用于描述如何验证这次修改的代码。它有四种方式，分别是（1）自动化验证；（2）手工验证；（3）Eyes；（4）TIP。

自动化验证：通常只需要写出如何运行自动化验证脚本，如 Java 项目可能写 mvn test 就可能运行本次变更所需要的测试用例。具体使用哪个命令，由作者根本实际情况确定。 手工验证：通常不容易写自动化测试用例，或还没有写。此时应该列举本次修改所需要的手工验证场景，如前图例。手工验证：就是指需要专业测试人员进行测试验证。Eyes：有一些变更比较简单（如配置项），或者无法或很难构造用于验证的运行场景，可以写 ‘eyes’。此时，评审者须格外给予关注。TIP：是指 Test in Production，表示只能在生产环境上验证。在这种情况下，需要工程团队格外给予关注。脚注

脚注与内容体之间以空行分隔。

脚注内容包括两部分，一是Relnote ，二是关联单号，二者之间以一行空白分隔。且两项均为可选项，应根据实际情况填写。

Relnote

Relnote 的内容将由工具自动生成 ChangeLog 。通常是该未来版本发布中比较重要的变更，既可能是重要的新特性，也可能是重大缺陷的修复。 若本变更需要写入 ChangeLog ，则需要有 Relnote。否则，可以不写 Relnote 段落。

Relnote 格式如下：

//这里空一行Relnote:用户可以通过点击 unlike , 屏闭自己不喜欢的广告。

作为关键字，独占一行。另起一行，填写具体ChangeLog内容。且二者之间不留空行。

关联单号

关联单号是指：本次提交变更与哪些工单关联。

根据原子性提交原则，一般只与一个单号相关联。

只有类似“当本次只修改一处，同时修复多个Bug”的情况下，才能够关联多个单号。

feat、fix 类型，必须与单号关联。

refector 类型，如果重构内容较大，建议先建立任务单，然后与重构任务单关联。如果是在当前开发某个特性或修复某个 bug 的工作，与该需求单或 bug 单相关联。

关联单号的格式必须使用以下几种：

story：#12345fix：#56789issue：#23456代码回滚（Revert）时的注释写法

如果某次提交是回滚（Revert）之前某一次提交的内容，主题行应该以revert:开头，然后写这次Revert提交的主题内容。

在内容部分，应该写:

本次 Revert 的提交是 < hash >。

其中，hash 部分应该填写被回滚的那一次提交的 SHA 值,并且当过程标准化以后，这个Revert操作可以完全通过自动化工具完成。

总结好的提交注释能让代码评审事半功倍。提交注释的作用：让评审者快速了解本次变更的意图、可通过脚本生成变更日志（changelog）、帮助评审者快速识别和过滤不重要的代码变更、浏览变更历史时可快速得到更多有用的信息。一个规范且有效的提交注释包括：主题行、内容体、脚注三大块内容。参考文档持续交付2.0：如何写好提交注释

论文格式排版|脚注如何插入？

有很多大学生论文写完了，却不会插入脚注，也就是参考文献的那一部分，今天就给大家分享一下插入脚注的方法，保证很快学会！

首先，打开WPS文档，光标移动到文中需要添加脚注处（一般应该在标点符号之前），点击“引用”“插入脚注”。

则文中出现了上标“1”如下图所示。

后面继续添加会依次显示“2”“3”……，页面底部出现了脚注分隔线和脚注编号，如下图。

这个格式可以根据你论文格式的需要而修改一下。右键点击脚注的小数字“1”然后选择脚注和尾注，然后在编号格式里选择你想要的编号形式，如下图。

接下来就可以点一下上面导航栏的尾注/脚注分隔线，然后在页脚1处写上本处文献的来源即可。

这就是插入脚注的方法，大家学会了嘛？有任何问题欢迎留言咨询！