Git（ギット）はプログラムのソースコードの変更履歴を記録するための分散型バージョン管理システムです。
主にアプリケーション開発の分野で利用されてきましたが、インフラの世界でも設定書の管理に利用することもあるので今回はインフラエンジニア目線で整理してみました。
分散型アーキテクチャ
Gitでは、各ユーザのローカル環境に全履歴を含んだ「リポジトリ」と呼ばれるデータ群の複製を持ち、そのローカルリポジトリに変更を加えていきます。
この仕組みは「分散型」と言われ、リモートに唯一のリポジトリを持って管理する「集中型」と呼ばれるものと比べて以下の特徴があります。
- ネットワークにアクセスできない状況でも利用可能
- 開発者同士が調整不要で変更が可能
- 履歴調査や変更がローカルで完結するので高速
- リモートサーバが消滅してもローカルデータからデータ復元可能
分散型のデメリットとしては、「リポジトリに関わるユーザの作業状況の把握が集中型と比較すると困難」な程度です。
変更履歴が管理できる仕組み
Gitの特徴として「一時点のスナップショットをバックアップとして記録する」というものがあります。
データベースで言うところのフルバックアップをとるため、大きなファイルの一部を修正したとしても世代管理をするために全てをバックアップとして取得します。
逆に、他のバージョン管理システムであるところのSubversionやCVSは初期ファイルとその差分で管理をします。
一見、差分でバックアップを取ることに合理性がありそうですが、フルバックアップを取っていることで分散型アーキテクチャが実現できています。ローカルで独立した開発が行えるのも、Gitが一時点のスナップショットを丸ごと取得する所以です。
一連の流れ
Gitでは「ファイルの修正」→「ファイルをステージング」→「ファイルをコミット」
という流れでバージョン管理を行います。
特にステージングとファイルをコミットは差が分かりにくいですが、基本は『一つのコミットにはその修正を無関係な変更は含めない』という原則があります。
例えば新機能Aと新機能Bを作成するために同時にいくつかのファイルを修正していた際も、同時にコミットせずにまずは新機能Aに関与したファイルをステージングし、コミット。その後に新機能Bに関与したファイルをステージングし、コミット、と関連性を気にせず異なる観点で変更を加えても、コミット前に関連性の強い変更だけをまとめてステージングすることができます。
ちなみに、論理的に整理されたコミットを行うためにはコメントにて「修正の目的」と「修正内容」を丁寧に記載することが重要です。
実際のコマンド群
ローカルPCにリポジトリのクローンを作成する
$ git clone ...
リポジトリの状況を確認
$ git status
ファイルをステージング
$ git add ...
ファイルをコミット
$ git commit -m"hogehoge"
hogehoge部分にコミットメッセージを入れます。
変更箇所の確認
$ git diff
コミット履歴を確認
$ git log
リモートリポジトリにコミット履歴を送信する
$ git push origin master
終わりに
まずはローカル環境で履歴管理に利用してみるのがいいかもしれません。
一般的には以下のように別名ファイルを作成しながら変更しますが、見た目のファイル群がすっきりするのでgitの利用はおすすめです。
$ cp hoge.sh hoge_bk.sh
以上、ご参考になれば幸いです。
