WALUDO ツール
DOCS.01 WALUDO DOCS

Git メモ

設定、ブランチ、コミット、マージ、取り消し、リモートリポジトリ、Conventional Commits をまとめた Git コマンドリファレンス。編集してコピーできる例も掲載しています。

クイックナビゲーション

よく使うコマンド

以下のコマンドの多くは it-tools.tech をもとに、日常の開発経験から補足しています。

コードブロック内の青い文字は編集できるため、すぐに変更してコピーできます。

設定

グローバルのユーザー名とメールアドレスを設定します。

bash 
git config --global user.name "WaLudo"
git config --global user.email "waludo@gmail.com"

新しいプロジェクトを始める

新しい Git リポジトリを初期化します。

bash 
git init

既存の Git リポジトリをクローンします。

bash 
git clone https://github.com/WaLudo/waludo-tools.git

コミット

追跡中の変更をすべてコミットします。

bash 
git commit -am "feat: add two cups of coffee"

すべての変更をコミットします。

bash 
git add .
git commit -m "feat: add five cups of coffee"

新しい変更を直前のコミットに追加します。

bash 
git commit --amend --no-edit

失敗してしまったとき

直前のコミットメッセージを編集します。

bash 
git commit --amend

変更を残したまま直前のコミットを取り消します。

bash 
git reset HEAD~1

変更を残したまま直近 N 件のコミットを取り消します。

bash 
git reset HEAD~N

直前のコミットを取り消し、すべての変更を破棄します。

bash 
git reset HEAD~1 --hard

ローカルブランチをリモートの状態に戻します。

bash 
git fetch origin
bash 
git reset --hard origin/branch-name

その他

ローカルの master ブランチを main に名前変更します。

bash 
git branch -m master main

コミット規約

Conventional Commits v1.0.0 の仕様を参照してください。

コミットを検証する

git commit -m "feat(scope): description"

Type のクイックリファレンス

Type説明
fixバグを修正する
feat新機能を追加する
buildビルドシステムを変更する（依存関係、外部インターフェース、Node バージョンなど）
choreビジネスロジック以外を変更する（ビルド手順、ツール設定など）
ci継続的インテグレーション設定（CI/CD）を変更する
docsドキュメントを変更する（README、API ドキュメントなど）
styleロジックを変えずにコードの書式を変更する
refactor動作を変えずにコードを再構成する
perfパフォーマンスを改善する
testテストケースを変更する

Scope

Type の後ろに括弧で Scope を付け、追加の文脈を示せます。

feat(parser): adds ability to parse arrays

破壊的変更

感嘆符は破壊的変更を示し、どの Type にも付けられます。

feat(api)!: send an email to the customer when a product is shipped

フッターに BREAKING CHANGE を含めても同じ意味になります。

複数行の本文とフッター

複数行の本文とフッターを持つコミットの例です。

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

完全な仕様

この文書にある MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL の意味は RFC 2119 に従います。

  • 各コミットは Type で始め、OPTIONAL の Scope、OPTIONAL の感嘆符、REQUIRED のコロンと半角スペースを続けます
  • 新機能には Type の feat を MUST 使用します
  • バグ修正には Type の fix を MUST 使用します
  • Scope は Type の後ろに MAY 付けられ、コードの一部を表す名詞を括弧で囲む必要があります。例: fix(parser):
  • 説明は type と scope のプレフィックスにあるコロンとスペースの直後に MUST 続けます
  • 短い説明の後に長い本文を MAY 置けます。本文は空行の後に MUST 始めます
  • 本文の後に空行を置いて一つ以上のフッターを MAY 置けます。各フッターは token と区切り記号を MUST 含みます
  • フッターの token は空白の代わりにハイフンを MUST 使います。例外として BREAKING CHANGE は token にできます
  • 破壊的変更はプレフィックスの感嘆符、または BREAKING CHANGE: 説明というフッターで MUST 示します
  • 感嘆符を使う場合、フッターの BREAKING CHANGE: は MAY 省略できます。説明には変更内容を SHOULD 書きます
  • feat と fix 以外の Type も MAY 使用できます。例: docs: updated ref docs.
  • 仕様を実装するツールは BREAKING CHANGE だけを除き、大文字小文字を区別せずに MUST 解析します
  • フッター token の BREAKING-CHANGE は BREAKING CHANGE と同義として MUST 扱います