tanaka101

Gitの仕組み

ワーキングツリー・ステージ・リポジトリの3つのエリアを理解しよう

Git とは

Git(ギット) は、世界で最も広く使われているバージョン管理システムです。

2005年に Linux の生みの親である Linus Torvalds が開発しました。現在では、ほぼすべてのソフトウェア開発プロジェクトで Git が使われています。

Git を使うと、ファイルのコピーを作る代わりに「変更の記録(コミット)」を積み重ねていきます。

ファイルを編集変更を選択 (add)記録する (commit)履歴に追加

この「コミット」という記録が、Git の最も基本的な単位です。

3つのエリア

Git には、ファイルが通過する 3つのエリア があります。

Gitのワークフロー

ワーキングツリー(作業フォルダ)

あなたが実際にファイルを編集する場所です。 普段VS Code などので作業していると思いますが、その作業場所こそがワーキングツリーです。

ステージ(インデックス)

コミットに含める変更を選ぶ場所です。 git commitすると変更履歴として保存されます。

なぜこのステージングという機能が必要なのかについては、後ほど説明します。

リポジトリ

変更履歴が保存される場所です。プロジェクトの .git フォルダの中にあります。

ここまでの流れはすべて(自分のPC)の中でのお話です。 変更履歴を他の人と共有するには、gitをベースに作成されたサービスを使って(インターネット上)に保存します。

代表的なサービスとして GitHubBacklogGitLab などが挙げられます。 今回は GitHub について解説します。

なぜ add → commit の2ステップなのか

開発中にバグを見つけて修正したとします。修正のために header.htmlstyle.cssapp.js の3つのファイルを変更しました。

もしステージがなく、変更したファイルがすべて自動でコミットされるとしたらどうでしょう? 同じタイミングで編集していた別の作業(例えばデザイン調整)も一緒にコミットされてしまいます。

git add があることで、関連するファイルだけを選んで、意味のある単位でまとめてコミットできます。

# バグ修正に関係する3ファイルだけをステージ
git add header.html style.css app.js
git commit -m "ヘッダーの表示バグを修正"
 
# デザイン調整は別のコミットにする
git add style.css
git commit -m "フッターのデザインを調整"

こうしてコミットを意味ごとに分けておくと、後から履歴を見たときに「いつ・何を・なぜ変更したか」が分かりやすくなります。

実際に手を動かしてみないと理解が難しいかもしれません。今は、やんわりと理解しておいてください。

セクションまとめ

  • Git には「ワーキングツリー → ステージ → リポジトリ」の3つのエリアがある
  • git add でステージに追加し、git commit でリポジトリに記録する
  • 2ステップに分かれているおかげで、関連する変更だけをまとめてコミット(記録)できる