今までGitの操作はSourceTreeを使っていたのでコマンドでもGitを操作できるようにしようと思い，いろいろ調べたので記事にしたいと思います．
Gitリポジトリを作成する
Gitで管理したいディレクトリ下でgit initコマンドを使用します．
$cd Gitで管理したいディレクトリへのパス // ディレクトリに移動
$git init // 移動したらgit initコマンドでリポジトリを作成
これで，このディレクトリはGitで管理されるようになりました．
Gitリポジトリの状態を確認する
Gitリポジトリができたので，ファイルを作成・編集してみましょう．
ディレクトリ内にtest.txtというファイルを作成します．
$echo 'Hello, Git!' > test.txt
$cat test.txt
Hello, Git!
ディレクトリ内では次々と状態が変更しているのでgit statusコマンドで状態を確認できます．
$git status
コミットする
ローカル環境下でのファイルの管理には次の3つの場所があります．(図１)
-
作業ディレクトリ
今編集しているファイルやディレクトリを格納しておく場所 -
ステージング・エリア
ファイルをコミットする前に変更内容を一時的に登録しておく場所
ここに追加されたファイルは次回コミット時にリポジトリに登録される -
ローカルレポジトリ
リモートリポジトリに送るためのコミットを登録する場所
図１ ローカル環境下でのファイルの管理
この図を見ると，作業ディレクトリでの変更内容をリポジトリに登録するには以下の手順が必要であることがわかります．
【コミットまでの手順】
- addコマンドでステージングエリアに変更内容を一旦登録する(ステージング)
- commitコマンドでリポジトリにコミットする
$git add test.txt // ファイルを指定してステージング
$git commit
ステージングする必要ってあるの？
実際には，上記の手順でコミットするわけですが一気にコミットすればいいのでは？と考えてしまいます．
でも，やっぱり意味があるんですね．
<例>
例えば，「ユーザーログインの機能を修正中に，ログイン画面のデザインまで修正してしまった」とします．
この場合，ステージングを行わなければ全ての変更が1つのコミットとしてリポジトリに保存されます．(図２左)
この例のように機能とデザインを一度に修正したコミットは，後から変更点の差分を見直す時に機能の修正とデザインの修正といった複数の意味が含まれた変更点が混在して表示されてしまったり，コミットメッセージには「ログイン機能の変更」のように片方の変更についてしか言及されなかったりとのちの混乱を引き起こす原因となる可能性があります．
ステージングを用いることにより関連性が強い変更点をまとめ，変更内容ごとにコミットすることができる．(図２右)
図２右のように，1回のコミットは関連性が強いものだけにまとめつつ小さくすることで，他の箇所への影響をできるだけ抑えながら，バグの原因箇所の特定や変更の取り消しが容易に行えるようになる．
図２ ステージングをする場合としない場合の違い
改めて勉強してみると，ちゃんとした理由があってこういった仕様になっているんだと思いました．
参考文献
書籍：「エンジニアのためのGitの教科書 実践で使える！バージョン管理とチーム開発手法」
今回の記事は以上になります．Gitに関しては引き続き勉強して記事をあげようと思います．
間違っている点や理解が不十分な点等，ご指摘いただければ幸いです．