En el trabajo de desarrollo diario, generalmente se usa git para administrar el código del proyecto. Después de modificar el código, el código se puede enviar a través del comando git commit.
Git estipula que la información de envío debe escribirse al enviarla, como una descripción del cambio, y debe guardarse en el historial de confirmación para una fácil retrospección. El registro estandarizado no solo es útil para que otros lo revisen, sino que también puede generar CHANGELOG de manera efectiva e incluso mejora en gran medida la calidad de la investigación y el desarrollo del proyecto.
Sin embargo, en el trabajo diario, la mayoría de los estudiantes simplemente escriben y escriben información de registro y no le prestan mucha atención, lo que sin duda es poco amigable para la gestión y el mantenimiento de proyectos. Este artículo se basa principalmente en mi propia experiencia para compartir contigo algunas especificaciones de git commit, de modo que tu registro no solo sea "atractivo" sino también "práctico".
¿Por qué deberíamos estandarizar el mensaje de confirmación? Se
ha dicho que deberíamos estandarizar el formato del mensaje de confirmación, entonces, ¿por qué deberíamos hacer esto?
Veamos primero un registro de compromiso no estándar: 
cómo te sientes después de leerlo, lo que se ha actualizado al final, todo es actualización escrita, este tipo de información de compromiso es sin duda uno para aquellos que quieren obtener información efectiva de Un golpe fatal.
Entonces echemos un vistazo al registro de confirmación de la especificación Angular más popular en la comunidad: 
¿Está claro después de leerlo?
La información de confirmación estandarizada en la figura anterior proporciona en primer lugar más información histórica para una navegación rápida. En segundo lugar, se pueden filtrar determinadas confirmaciones (como los cambios en los documentos) para facilitar la búsqueda rápida de información.
Ahora que la especificación del equipo de Angular es la especificación de compromiso más popular en la comunidad, ¿qué es exactamente? Echemos un vistazo más de cerca.
La especificación de confirmación del equipo de Angular y
su formato de mensaje son los siguientes:
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>Corresponde a las tres partes del mensaje de confirmación: encabezado, cuerpo y pie de página.
Encabezado La
parte Encabezado tiene solo una línea, incluidos tres campos: tipo (obligatorio), alcance (opcional) y asunto (obligatorio).
tipo: se utiliza para indicar el tipo de compromiso. Generalmente existen los siguientes:
feat: new featurefix: fix bugdocs: solo modifica el documento, como readme.mdstyle: solo modifica el formato, como coma, sangría, espacio, etc. No cambie la lógica del código. refactorización: refactorización de código, sin nuevas funciones o correcciones de errores perf: relacionado con la optimización, como mejorar el rendimiento, la experiencia del usuario, etc. prueba: casos de prueba, incluidas las pruebas unitarias y las pruebas de integración. tarea: cambie el proceso de compilación o agregue bibliotecas, herramientas, etc. reversión:
alcance de reversión de la versión : se utiliza para describir el alcance del impacto de la confirmación, como: vistas, componente, utilidades, prueba ...
Asunto: una breve descripción del propósito de la confirmación
La
descripción específica del cuerpo del contenido de la modificación de este commit, que se puede dividir en varias líneas. Como se muestra abajo:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commitEl pie de página tiene
algunos comentarios, generalmente un CAMBIO IMPORTANTE (el código actual no es compatible con la versión anterior) o un enlace a un error corregido (cerrar Problema).
Después de presentar brevemente las especificaciones anteriores, hablemos de commit.template, que es la plantilla de información de envío de git.
Plantilla de información de envío de git
Si su equipo tiene requisitos de formato para la información de envío, puede crear un archivo en el sistema y configurar git para usarlo como la plantilla predeterminada, lo que facilita que la información de envío siga el formato.
Utilice el siguiente comando para configurar la plantilla de información de envío:
git config commit.template [模板文件名] //这个命令只能设置当前分支的提交模板
git config — —global commit.template [模板文件名] //这个命令能设置全局的提交模板，注意global前面是两杠El contenido del nuevo .gitmessage.txt (archivo de plantilla) puede ser el siguiente:
# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the issue.
# - BREAKING CHANGE
#Después de leer lo anterior, ¿sentirás que la configuración es problemática como yo? Parece que no es fácil configurar una especificación de compromiso casi perfecta que se adapte a ti y a tu equipo. Sin embargo, la comunidad también nos proporciona algunas herramientas auxiliares para ayudar con el envío. Vamos a presentar brevemente estas herramientas.
commitizen
commitizen es una herramienta que puede crear de forma interactiva información de envío y puede generar automáticamente mensajes de confirmación calificados
Instale
npm install -g commitizen
y use
commitizen init cz-convencional-changelog --save --save-exact
commit en el proyecto.
Puede usar git cz al enviar. Luego puede generar un mensaje de confirmación automatizado de acuerdo con las indicaciones. 
Cuando usando Commitizen, primero use las teclas arriba y abajo para controlar el tipo que desea, correspondiente a la hazaña, corrección, documentos, perf, etc. mencionados anteriormente, y luego le permite seleccionar los archivos afectados por este envío, y luego le permite escribir una breve por separado y una descripción detallada del envío, y finalmente le permite juzgar si este envío es un CAMBIO IMPORTANTE o está relacionado con un problema abierto. Finalmente, al ver el historial de confirmaciones en ese momento, verá un mensaje de confirmación como este:
docs (docs): actualiza el archivo README
validate-commit-msg
commitizen puede garantizar sus propias especificaciones de mensajes de confirmación locales, pero no puede garantizar que los compañeros de equipo también estén estandarizados, por lo que se necesitan otras herramientas para verificar si los registros de envío de los compañeros de equipo están estandarizados. Use validate-commit-msg para verificar la especificación del mensaje de confirmación de los compañeros de equipo
安装
npm install validate-commit-msg husky -D
添加 package.json 文件 配置
"husky": {"hooks": {"commit-msg": "validate-commit-msg"}}
自 定义 校验 格式 （可选）
添加 一个 .vcmrc 文件 ， 配置 对象 如下 ：
{"types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", " ci "," tarea "," revertir "]," alcance ": {" obligatorio ": falso," permitido ": [" "]," validar ": falso," múltiple ": falso}," warnOnFail ": falso , "maxSubjectLength": 100, "subjectPattern": ". +", "subjectPatternErrorMsg": "¡el tema no coincide con el patrón del tema!", "helpMessage": "","AUTOFIX": false}
Envío
ejemplo: git commit
-m'feat (main.js): ruta Añadir' para generar CHANGELOG'
convencional de cambios instalar
NPM instalar -g-cambios-cli convencional
# Genere CHANGELOG.md y sobrescriba el contenido anterior convencional-changelog -p angular -i CHANGELOG.md -s -r 0 # Genere todos los cambios liberados Log logconventional-changelog -p angular -i CHANGELOG.md -w -r 0
Note
convencional- changelog -p angular -i CHANGELOG.md -w solo puede registrar el contenido de CHANGELOG en la línea de comando, y no generará archivos. Si desea generar archivos, necesita usar convencional-changelog -p angular -i CHANGELOG. md- s. Se pueden ver más configuraciones usando convencional-changelog --help *