職場でSVNからGitにバージョン管理ソフトを変更する事になった。
今年から切り替わりもう三ヶ月たつが、正しく理解して使えていないのを実感しているので１から勉強し直す。

下記教本を読みながら、後で自分で見返した時に分かりやすいようにまとめてみる。
つまり間違った内容や自分流に分かりやすくしてあったりもする。

教本

Gitとは

バージョン管理で分散型に分類される。

集中型
SubversionやVCSのようなバージョン管理のこと。
名前の通り一つのサーバーに集約して全体のソースを管理する
分散型
Gitはこちらに分類される。
クライアントへサーバー側の持っている情報全て（過去の更新履歴を含めたリポジトリ全体）をミラーリングする。
故にネットワークに接続していない状態でも、ローカルでさらに分岐して開発することが出来る。

３つのエリアがある
ワーキングディレクトリとステージングエリアとリポジトリ。

ワーキングディレクトリ
Gitでバージョン管理の対象にしたプロジェクトの、実際に編集などするファイルのあるところ。
Eclipseで言えば普通のワークスペース以下のソースコード。
ステージングエリア
リポジトリへコミットをするファイルを選択してまとめておくエリア。
コミットを実行すると、ここにまとめてあるファイルがリポジトリにまとめて登録される。
リポジトリ
SVNと同じバージョン管理をしている本体。
コミットを行うとここに登録される。

つまり
例えばある画面にファイルアップロード機能とデザインの修正が入る事になった。
アップロードボタンを作成し、アップロード用の処理を追加修正した。
それとは別にデザインの修正もした。

で、これがまとめて一つのコミットとだと、あとで見た時にソース上のどの修正がどっちの機能に対しての修正か分かりづらい。

なので、コミットを分ける事にする。
ワーキングディレクトリ：修正したファイルのうちアップロード機能用のファイルをステージングする
ステージングエリア：ステージングされたファイルをまとめてコミット
リポジトリ：このコミットを「アップロード機能用のコミットとして残す」

こういうことね

ワーキングディレクトリの変更を監視してくれている。

untracked（未追跡）

新規に作成されたファイルなど、ステージングを提案されない状態のファイル

unmodified（未変更）

ワーキングディレクトリで変更のあったファイルをステージングエリアへ格納する候補として認識した状態

modified（編集済み）

ワーキングディレクトリで変更のあったファイルをステージングエリアへ格納する候補として認識した状態

staged（ステージ済み）

ステージングエリアに格納された状態
この状態になるとtracked（追跡）状態となり、以降の変更は常にステージングする候補として提案される。