提交Git commit 以及.gitmessage文件

2 年 ago
清, 宇
1 minute

在Git中，提交信息的编写没有特定的限制，你可以随意写自己喜欢的方式。然而，如果你传达的意思难以整理，或者只做随意的提交，以后查看历史记录就会变得困难。设定一定的规范可能会提高工作效率。

提交Git命令

如果你想打开你喜欢的编辑器并写信息的话，只需输入命令而无需添加任何选项。

git commit

好像有多种方法可以指定在 Git 中使用的编辑器。

 

如果您想在终端内完全完成操作，您可以使用-m选项直接传递消息。

git commit -m "元氣があれば何でもできる"

如果你想要创建多个段落，你可以多次使用 -m 选项来实现。它们会以一行的间隔连接在一起。如果你想用你喜欢的编辑器进行编辑，同样也可以通过空一行来将它们分成多个段落。

git commit -m "概要" -m "本文" -m "脚注"

–cleanup= 选项可以在初始设置中自动删除以“＃”开头的注释以及消息前后的空白字符。通常情况下，我认为不需要修改此选项，但了解此特性可能会有所帮助。最终会变为空的提交将被视为无效，除非明确允许它。请参考原始文档获取详细信息。

 

在Git的提交消息中制定规定

在进行网络搜索时，许多人建议在提交概要中添加前缀。看起来这些建议是基于与Angular相关的项目的约定。首先需要查阅原始资料可能是个好主意。

 

我们对Git提交消息的格式有非常精确的规定。这种格式使得提交历史更易于阅读。

为了使提交记录更加易读，特别是针对Git提交消息的格式，据说制定了严格的规范。

构成

    1. 摘要

 

    1. 空行

 

    1. 本文

 

    1. 空行

 

    注解

写概要的方法。

xxx(yyy): zzz
│    │    │
│    │    └─⫸ 現在形での要約（小文字で、最後のピリオドなし）
│    │
│    └─⫸ 影響を受ける範囲、パッケージ等
│  
└─⫸ コミットタイプ

Angular团队使用以下类型的提交：

build: ビルドシステムまたは外部依存関係に影響を与える変更

ci: CI 関連のファイルとスクリプトへの変更

docs: ドキュメントのみの変更

feat: 新機能

fix: バグ修正

perf: パフォーマンスを向上させるコード変更

refactor: バグの修正も機能の追加も行わないコード変更

test: 不足しているテストの追加または既存のテストの修正

看到各种文章时，似乎也有人将以下内容作为提交类型之一。

BREAKING CHANGE: 破壊的変更 (セマンティック バージョニング の メジャーバージョンが上がる時)

chore: 依存性など

style: 空白、セミコロン、字下げなど

这篇文章的写作方式

    • 概要と同様に、現在形で。

 

    • コミットメッセージ変更した動機や理由を説明。

 

    変更の影響が把握しやすいよう、以前の動作と新しい動作の対比をここに示してもよい。

写脚注的方式

    • 破壊的変更（BREAKING CHANGE）や非推奨（DEPRECATED CHANGE）に関する情報

 

    関連する GitHub issues、pull requests、Jira チケットなど
BREAKING CHANGE: <破壊的変更の要約>
<空白行>
<破壊的変更の説明 + 移行手順>
<空白行>
<空白行>
Fixes #<issue 番号>

DEPRECATED: <何が非推奨になるのか>
<空白行>
<非推奨の説明 + アップデート手順>
<空白行>
<空白行>
Closes #<pull-request 番号>

有很多可以参考的。作为下一步，还有一个问题需要解决，那就是如何将希望应用的规约变得习惯化。每次写提交信息时参考规约文件还是很麻烦的，而且记住也很困难。这样就很难形成一种习惯。作为解决方案之一，可以使用Git提交信息模板。

创建 Git 提交信息的模板

您可以自定义在执行git commit命令时所显示的内容，使用您喜欢的编辑器。您可以在这里记录适用于您希望应用的规范和书写方式。方法很简单。

    1. 创建一个名为~/.gitmessage的文件，并写入模板。

运行git config –global commit.template ~/.gitmessage命令，将上述模板注册。

 

例如，您可以创建这样的模板。我不知道是谁决定的，但似乎有推荐的字数。



# ## 概要
# xxx(yyy): zzz
# ------ 50 charcters -------------------------->|


# ## 本文
# ------ 72 charcters ------------------------------------------------>|


# ## 概要の書き方
#
#   xxx(yyy): zzz
#   │    │    │
#   │    │    └─⫸ 現在形での要約（小文字で、最後のピリオドなし）
#   │    │
#   │    └─⫸ 影響を受ける範囲、パッケージ等
#   │
#   └─⫸ コミットの種類
#
# - build: ビルドシステムまたは外部依存関係に影響を与える変更
# - ci: CI 関連のファイルとスクリプトへの変更
# - docs: ドキュメントのみの変更
# - feat: 新機能
# - fix: バグ修正
# - perf: パフォーマンスを向上させるコード変更
# - refactor: バグの修正も機能の追加も行わないコード変更
# - test: 不足しているテストの追加または既存のテストの修正
# - chore: 依存性のアップデートなど
# - style: 空白、セミコロン、字下げなど
#
# ## 本文の書き方
# 
# - 概要と同様に、現在形で。
# - コミットメッセージ変更した動機や理由を説明。
# - 変更の影響が把握しやすいよう、以前の動作と新しい動作の対比をここに示してもよい。
# 
# ## 脚注の書き方
# 
# - 破壊的変更 (BREAKING CHANGE) や非推奨 (DEPRECATED) に関する情報
# - 関連する GitHub issues、pull requests、Jira チケットなど
#
#   BREAKING CHANGE: <破壊的変更の要約>
#   <空白行>
#   <破壊的変更の説明 + 移行手順>
#   <空白行>
#   <空白行>
#   Fixes #<issue 番号>
#
#   DEPRECATED: <何が非推奨になるのか>
#   <空白行>
#   <非推奨の説明 + アップデート手順>
#   <空白行>
#   <空白行>
#   Closes #<pull-request 番号>

每次提交时显示一条让你精神焕发的消息，可能会让你振奋起来。由于会删除以“＃”开头的注释，所以可以尝试任何内容。

# 元氣ですかーーーーッ！ 元氣があればなんでもできる

 

思考最强的提交信息

有很多人提出了最強的规则建议。这些可能会作为参考。过于深入思考似乎是本末倒置，也许轻松地去做会更好。

在Qiita上搜索可以找到各种各样的结果，而且还可以找到很多英文文章。

 

可以了。

CleanShot 2023-06-03 at 15.09.48.png

提交钩子

我收到了读者 @RyoWakabayashi 发来的信，他说他总是通过 commitlint 来强制使用传统的提交方式。非常感谢！

 

木木会

这篇文章是关于在以下的“MoMoKai”组织中取得的成果。感谢大家给予我刺激和活力。

 

如果您有兴趣，请随意参加。

 

bannerAds