Git: Gitのコミットとコミットメッセージのガイドラインに関する詳細ガイド

Q: 提出後にファイルの提出漏れに気づいた場合はどうすればよいですか？

git add を使用して不足しているファイルを追加し、その後 git commit --amend --no-edit を実行してそれらを最後のコミットに追加してください。注：プッシュされていないコミットのみ変更可能です。

Q: 直前のコミットを元に戻すにはどうすればよいですか？

git reset --soft HEAD~1 を使用すると、コミットを元に戻しつつ変更内容をステージング領域に残すことができます。 git reset --mixed HEAD~1 を使用すると、コミットを元に戻して変更内容を作業ディレクトリに戻します。 git reset --hard HEAD~1 を使用すると、変更内容を完全に破棄します。

Q: 特定のコミットの詳細を確認するにはどうすればよいですか？

git show <commit-id> を使用すると、コミットのメタデータやファイルの変更点など、特定のコミットの詳細を確認できます。パラメータを指定せずに git show を使用すると、最新のコミットを確認できます。

Q: コミットしようとしたときに「コミットする内容がありません」と表示されるのはなぜですか？

これは、ステージング領域が空であることを意味します。まず git add を使用して変更をステージングするか、 git commit -a を使用して追跡対象のファイルの変更を自動的にステージングする必要があります。

コミットはGitの中核となる操作です。コミットを行うたびに、特定の時点におけるプロジェクトの完全な状態を記録した一意のバージョンスナップショットが作成されます。

1. 基本概念の提出

(1) コミットとは何ですか？

コミットはGitバージョン管理の基本単位であり、以下の情報を含んでいます：

スナップショット：特定の時点における、追跡対象のすべてのファイルの完全な状態
メタデータ：著者情報、投稿日、投稿の詳細
親コミット：直前のコミットへのポインタ（最初のコミットを除く）
一意の識別子：40文字のSHA-1ハッシュ値

graph TB
    A[Workspace<br/>Working Directory] -->|git add| B[Buffer<br/>Staging Area]
    B -->|git commit| C[Repository<br/>Repository]
    C --> D[Generate a commit object<br/>Commit Object]
    D --> E[SHA-1Hash<br/>a1b2c3d4e5f6...]
    
    style A fill:#fff3cd
    style B fill:#d4edda
    style C fill:#c3e6cb
    style E fill:#cce5ff

(2) 提出手続き

提出手続き全体は、以下の3つのステップで構成されています：

ファイルの変更：ワークスペース内のファイルを編集する
ステージの変更：git add を使用して、ステージングエリアに変更を追加します
コミットを作成する：git commit を使用して、ステージングエリアの内容をリポジトリにコミットします

(3) 提出の目的

バージョン履歴：特定の時点におけるプロジェクトの状態を完全に保存します
バージョン履歴：いつでも任意のバージョンを確認したり、そのバージョンに戻したりすることができます
コラボレーションの基本：チームメンバーはコミットに基づいて共同作業を行うことができます
変更内容：この変更の詳細を提出メモに記載してください。

2. 投稿の基本操作

(1) 初回提出

▶ サンプル：初めてのコミットの作成

BASH

# Initialize the repository
git init

# Create a File
echo "# My Project" > README.md

# View Status
git status
# Untracked files:
#   README.md

# Add to Stash
git add README.md

# Submit
git commit -m "Initial commit"

# Output：
# [main (root-commit) a1b2c3d] Initial commit
#  1 file changed, 1 insertion(+)
#  create mode 100644 README.md

(2) 定期的な投稿

▶ サンプル：標準的な提出プロセス

BASH

# Edit File
echo "## Features" >> README.md

# View and Edit
git diff
# +## Features

# Add to Stash
git add README.md

# View Staging Status
git status
# Changes to be committed:
#   modified:   README.md

# Submit
git commit -m "Add features section"

# View commit history
git log --oneline
# a1b2c3d Add features section
# b2c3d4e Initial commit

(3) 一括送信

▶ サンプル：一括追加と送信

BASH

# Create Multiple Files
touch file1.js file2.js file3.js

# Add All Files
git add .

# Or add specific types of files
git add *.js

# Submit
git commit -m "Add multiple JavaScript files"

# View Submission
git show
# commit a1b2c3d4e5f6...
# Author: Zhang San <zhangsan@example.com>
# Date:   Mon Jan 1 10:00:00 2026 +0800
#
#     Add multiple JavaScript files
#
# diff --git a/file1.js b/file1.js
# new file mode 100644
# index 0000000..e69de29

3. 投稿ガイドライン

(1) 情報の提出の重要性

優れたコミットメッセージには、次のような特徴があります：

変更点を明確に説明する：チームメンバーが何が変更されたかを素早く理解できるようにする
履歴の追跡が容易：特定の機能に関する開発記録を簡単に見つけることができます
自動化ツールのサポート：変更履歴の自動生成に対応しています
コラボレーションの効率向上：コミュニケーションコストの削減

(2) 従来のコミット規格

これは現在最も一般的なコミットメッセージの規約であり、その形式は以下の通りです：

TEXT 📖 参照専用

<type>(<scope>): <subject>

<body>

<footer>

各セクションの説明：

タイプ（必須）：提出の種類
範囲（任意）：影響の範囲
件名（必須）：簡単な説明
本文（任意）：詳細な説明
フッター（任意）：フッター情報

(3) 提出形式

タイプ	説明	ユースケース
feat	新機能	新機能を追加
修正	バグ修正	プログラムエラーの修正
ドキュメント	ドキュメントの編集	ドキュメントの内容を更新
スタイル	コードの書式設定	コードの意味に影響を与えない書式変更
リファクタリング	リファクタリング	機能の追加やバグの修正を伴わないコードのリファクタリング
perf	パフォーマンスの最適化	コードのパフォーマンス向上
テスト	テスト	テストコードの追加または変更
タスク	ビルド／ツール	ビルドプロセスまたは関連ツールの変更点
ci	CIの設定	CIの設定ファイルを編集する
元に戻す	元に戻す	元に戻す前のコミット

▶ サンプル：標準的な提出情報

BASH

# Single-line commit - New Features
git commit -m "feat: Add User Login Functionality"

# Single-line commit - BugFix
git commit -m "fix: Fix the login authentication error"

# Range-Based Submissions
git commit -m "feat(auth): AddJWTCertification Support"

# Multi-line commit
git commit -m "feat(user): Add a user registration feature" -m "Supports registration via email and phone number" -m "Add Form Validation and Error Messages"

# Submission with Footer（CloseIssue）
git commit -m "fix: Fixed a styling issue on the login page" -m "Closes #123"

# Use the editor to write a detailed commit message
git commit
# It will open in the editor，You can write a detailed commit message

(4) 情報提出に関するベストプラクティス

適切なコミットメッセージ：

TEXT 📖 参照専用

feat(auth): AddOAuth2.0Login Support

- SupportGoogle、GitHub、WeChat Third-Party Login
- Add Login State Persistence
- Enable Auto-RefreshTokenMechanism

Closes #456

不適切なコミットメッセージ：

TEXT 📖 参照専用

update
fix bug
I made some changes.
WIP

4. 提出方法の詳細な説明

(1) 一般的なコミットオプション

オプション	説明	例
`-m`	情報を送信	`git commit -m "message"`
`-a`	追跡対象のファイルを自動的にステージング	`git commit -a -m "message"`
`--amend`	最後のコミットを編集	`git commit --amend`
`--no-verify`	コミットフックをスキップ	`git commit --no-verify -m "message"`
`--allow-empty`	空の提出を許可する	`git commit --allow-empty -m "message"`
`-s`	「Signed-off-by」を追加	`git commit -s -m "message"`

▶ サンプル：送信オプションの使用方法

BASH

# Auto-check-in and commit（Applies only to tracked files）
echo "new content" >> README.md
git commit -a -m "Update README"

# Add a signature
git commit -s -m "feat: Add a New Feature"
# Will be added to the submitted information：
# Signed-off-by: Zhang San <zhangsan@example.com>

# Skippre-commitHook
git commit --no-verify -m "WIP: Save as Draft"

# View Submission Details
git show HEAD

(2) テンプレートの送信

コミットテンプレートを設定することで、チームメンバーがコミットメッセージにおいて一貫した形式に従うようにすることができます。

BASH

# Create a commit template
cat > .git/commit-template << 'EOF'
# <type>(<scope>): <subject>
#
# typeAvailable values：
# feat, fix, docs, style, refactor, perf, test, chore
#
# subjectRules：
# - Using Imperative Sentences
# - Lowercase the first letter
# - Do not add a period at the end
EOF

# Configuring the Use of Templates
git config commit.template .git/commit-template

# Submit Using a Template
git commit
# It will open the editor，Display template content

5. 修正して送信する

(1) 最後のコミットを変更する

▶ サンプル：コミットメッセージの変更

BASH

# Edit the commit message for the last commit
git commit --amend -m "feat: Add User Login Functionality（After the correction）"

# Output：
# [main d4e5f6g] feat: Add User Login Functionality（After the correction）
#  Date: Mon Jan 1 10:00:00 2026 +0800
#  1 file changed, 1 insertion(+)

(2) ファイルを最後のコミットに追加する

▶ サンプル：不足しているファイルの追加

BASH

# Suppose you realize after submitting that you've left out a file
git add forgotten-file.txt

# Add to the last commit，Do not modify the commit message
git commit --amend --no-edit

# Or add to and modify the commit message
git commit --amend -m "feat: Add user login functionality and related configurations"

(3) 投稿内容の著者情報を修正する

▶ サンプル：著者情報の編集

BASH

# Change the author of the last commit
git commit --amend --author="Li Si <lisi@example.com>"

# Edit Submission Date
git commit --amend --date="2026-01-01 10:00:00"

(4) 提出物の修正に関する重要な注意事項

graph TB
    A[Commit Changes] --> B{Has the commit been pushed??}
    B -->|Not pushed| C[Can be safely modified]
    B -->|Pushed| D[Forced push required]
    D --> E[May affect other developers]
    E --> F[Use with caution]
    
    style C fill:#d4edda
    style F fill:#f8d7da

⚠️ 重要な警告：

プッシュされていないコミットのみを変更する
プッシュ済みのコミットを変更するには git push --force が必要です
強制的なプッシュは他の開発者に影響を与える可能性があるため、事前の連絡が必要です。
チームで作業する際は、すでにプッシュ済みのコミットを変更しないように心がけてください

6. ベストプラクティスの提出

(1) アトミックコミット

各コミットには、1つの論理的な変更のみを含める必要があります：

ベストプラクティス：

BASH

# Submit1：Add Feature
git add feature.js
git commit -m "feat: Add User Login Functionality"

# Submit2：FixBug
git add fix.js
git commit -m "fix: Fix the login authentication error"

# Submit3：Update Documentation
git add README.md
git commit -m "docs: Update the Login Feature Documentation"

やってはいけないこと：

BASH

# A single commit containing multiple unrelated changes
git add .
git commit -m "Add Feature、FixBug、Update Documentation"

(2) 提出頻度

頻繁なコミット：小さく素早いステップを踏む。小さな機能を1つ完成させるごとにコミットする
完全なコミット：各コミットは、完全な状態を表すものであるべきです。
中途半端な作業は避ける：動作しないコードは提出しないでください

(3) 提出前の確認

▶ サンプル：提出前のチェックリスト

BASH

# 1. View the content to be submitted
git status

# 2. View Specific Changes
git diff

# 3. View the contents of the staging area
git diff --staged

# 4. Submit after verifying that everything is correct
git commit -m "feat: Add a New Feature"

# 5. View Submission Results
git show

(4) ファイル設定を無視する

.gitignore ファイルを使用して、提出する必要のないファイルを除外してください：

TEXT 📖 参照専用

# .gitignoreExample

# Dependency Directory
node_modules/
vendor/

# Compilation Output
dist/
build/
*.o
*.class

# IDELayout
.vscode/
.idea/
*.swp

# Environment Configuration
.env
.env.local

# Log Files
*.log
logs/

# Operating System Files
.DS_Store
Thumbs.db

❓ よくある質問

Q 提出後にファイルの提出漏れに気づいた場合はどうすればよいですか？

A git add を使用して不足しているファイルを追加し、その後 git commit --amend --no-edit を実行してそれらを最後のコミットに追加してください。注：プッシュされていないコミットのみ変更可能です。

Q 直前のコミットを元に戻すにはどうすればよいですか？

A git reset --soft HEAD~1 を使用すると、コミットを元に戻しつつ変更内容をステージング領域に残すことができます。git reset --mixed HEAD~1 を使用すると、コミットを元に戻して変更内容を作業ディレクトリに戻します。git reset --hard HEAD~1 を使用すると、変更内容を完全に破棄します。

Q 情報はどの言語で提出すべきですか？

A Git やほとんどのオープンソースプロジェクトでは英語が使用されているため、英語の使用をお勧めします。チーム内のプロジェクトでは中国語を使用することも可能ですが、その場合は一貫性を保つようにしてください。

Q 特定のコミットの詳細を確認するにはどうすればよいですか？

A git show <commit-id> を使用すると、コミットのメタデータやファイルの変更点など、特定のコミットの詳細を確認できます。パラメータを指定せずに git show を使用すると、最新のコミットを確認できます。

Q コミットしようとしたときに「コミットする内容がありません」と表示されるのはなぜですか？

A これは、ステージング領域が空であることを意味します。まず git add を使用して変更をステージングするか、git commit -a を使用して追跡対象のファイルの変更を自動的にステージングする必要があります。

📖 まとめ

コミットは、Gitの中核となる操作であり、あるバージョンのスナップショットを作成し、プロジェクトの履歴を記録するものです。
コミットの手順：ファイルを修正 → 変更をステージング → コミットを作成
「Conventional Commits」のガイドラインに従って、わかりやすいコミットメッセージを記述する
コミットオプションを使用して効率を向上させる：-a オプションで変更を自動的にステージングし、--amend オプションでコミットを修正する
すでにプッシュ済みのコミットを変更するには、フォースプッシュを行う必要がありますが、これにより他の開発者に影響が出る可能性があります。
コミットに関するベストプラクティス：アトミックなコミット、頻繁なコミット、およびコミット前のチェック

📝 練習問題

基本演習：Gitリポジトリを作成し、README.mdファイルを追加し、適切なコミットメッセージを付けて最初のコミットを行い、その後、コミット履歴を確認してください。
応用問題：コミット後にファイルが欠落していることに気づいたというシナリオをシミュレートしてください。--amend オプションを使用して、そのファイルを最後のコミットに追加し、コミットの内容を確認してください。
課題：コミットテンプレートを設定し、「Conventional Commits」ガイドラインに準拠したテンプレートファイルを作成し、そのテンプレートを使用してコミットを行い、コミットメッセージが指定された形式に従うようにします。

Web-Tutorial 技術チーム

複数の開発者によって共同維持されているプログラミングチュートリアルプラットフォーム。各チュートリアルは専門分野の開発者が執筆・レビューしています。正確で信頼性の高いコンテンツを目指しています — 問題を見つけた場合はお知らせください。

私たちについて