前回の記事では Gitの基本コマンド
git initgit addgit commit
を紹介しました。
今回はその中でも特に重要な
git add
git commitを もう少し深く解説します。
Gitを理解する上で一番重要なのは
ステージングという概念です。
この記事では次の内容を解説します。
- Gitの3つの状態
- ステージングとは
- git add の役割
- git commit の役割
- 実務での使い方
Gitの3つの状態
Gitではファイルは次の3つの状態を持ちます。
Working Directory
Staging Area
Repository順番に説明します。
Working Directory
Working Directoryは
作業中のファイルです。
例えば
app.js
index.html
style.cssなど、編集しているファイルです。
この段階では Gitの履歴にはまだ保存されていません。
Staging Area
Staging Areaは
コミット予定の変更を保存する場所です。
この状態にするには
git addを使います。
Repository
Repositoryは
Gitの履歴が保存される場所です。
ここに保存する操作が
git commitです。
Gitの状態イメージ
Gitの状態は次のような流れになります。
Working Directory
↓
git add
↓
Staging Area
↓
git commit
↓
Repositoryこの流れを理解することが Git理解の最重要ポイントです。
git add の役割
git add は
変更をステージングするコマンドです。
例
git add app.jsこのコマンドを実行すると
app.jsの変更が Staging Area に登録されます。
git add の例
例えば次のような状況です。
ファイル
app.js
style.cssを変更したとします。
その状態で
git statusを実行すると
modified: app.js
modified: style.cssと表示されます。
ここで
git add app.jsを実行すると
app.jsだけがステージングされます。
つまり
部分的にコミットができます。
git add . について
よく使われるコマンド
git add .これは
すべての変更をステージングします。
初心者はこれをよく使いますが、実務では
必要なファイルだけaddすることも多いです。
git commit の役割
git commit は
変更履歴を保存するコマンドです。
例
git commit -m "add login feature"このコマンドで
コミットが作成されます。
commitメッセージ
commitメッセージは
変更内容の説明です。
良い例
add login feature
fix header layout
update API request logic悪い例
fix
update
test履歴を読みやすくするために 意味のあるメッセージを書くことが重要です。
実務でのコミットの考え方
実務では次のルールがよく使われます。
小さくコミットする
例
ログインUI追加
↓
ログインAPI追加
↓
ログインバグ修正のように 変更単位ごとにコミットします。
機能単位でコミット
例
add login form
add login API
fix login validation1コミット1目的
コミットは
1つの変更を基本にします。
git commit -am
便利なコマンド
git commit -am "message"これは
add + commitを同時に行います。
ただし
新しいファイルには使えません。
git diff
コミット前に変更を確認するコマンドです。
git diffステージング済み
git diff --stagedこのコマンドは実務で非常によく使います。
Git作業の基本フロー
基本的なGit操作は次の通りです。
ファイル編集
↓
git status
↓
git add
↓
git commitこの流れを繰り返します。
まとめ
この記事では git add と git commit を詳しく解説しました。
重要なポイント
Working Directory
↓
git add
↓
Staging Area
↓
git commit
↓
Repositoryこの仕組みを理解すると Gitの動作がかなり理解しやすくなります。
次の記事
次回は
Gitブランチ
を解説します。
ブランチを理解すると
安全に機能開発ができるようになります。
コメント