開発​/バージョン管理システム​/git

Subversionでの管理方法

Subversionでは中央リジトリが1つあって，各ユーザーはリポジトリ*1からチェックアウトを行い，作業コピーを取得する。

作業コピーで必要な修正を行った後，修正内容をコミットとしてリポジトリへ反映する。
またリポジトリからの修正を取り込むために，アップデートを行ったりする。

このように常に管理対象のリポジトリが1つなので，特に操作に戸惑うことはない。

重要なのは，コミットという操作が共用リポジトリへ反映されるということなのだが，このことは，完全には機能しない途中段階のコードは，一切コミットできないことを意味するとも言える。

Gitでの管理方法

これに対してGitでは複数のリポジトリを使用する。

リモートリポジトリ*2から，クローンという作業でリポジトリの複製（ローカルリポジトリ）を作成する。

修正は複製したローカルリポジトリに対して行って，リモートリポジトリへ反映するにはコミットではなくプッシュという操作を行う。
コミットという操作もあるが，それはローカルリポジトリを対象とした操作のことになる。

この仕組みにより，ファイルを管理している格納先を中央の1箇所ではなく，いろいろな所に持てることになる。

Linuxカーネルの開発のはじめの頃は，開発している多くの人たちがLinux Kernel Mailing Listにパッチを投稿して，それをソースに反映させるという開発スタイルだったようだ。
これでは作業が大変だということで，あるバージョン管理システムを使ってみたのだが機能に問題があってGitを開発したらしい。

ということで，Linuxカーネルではすごい量のソースコード・変更点の抽出・リポジトリ操作なんかが日々あるわけで，これらの管理が問題なく行えているのでGitの性能は折り紙付きなわけです。

同じバージョン管理システムでも，中央集権型と分散型では作業手番が異なっていて，同じような操作名（例：コミット）でも，違った動作になったりするので時々混乱する。

Gitを使った作業フローとしては，

• リモートリポジトリからコピーする
  リモートリポジトリは専用のサーバに配置して，複数人で共有するためのリポジトリの事。
  そこから，ローカルリポジトリ（ユーザ一人ひとりが作業を行うために，自分の手元のマシン上に配置するリポジトリ）にファイルをコピーする。
  このローカルリポジトリから必要なファイルを，ワーキングディレクトリ（作業をする）に配置しておく。
  
• ワーキングディレクトリのファイルを編集し，コンテンツの修正・追加・削除などを行う。
  
• ローカルリポジトリへコミットする
  普段の作業はローカルリポジトリを使って，全て手元のマシン上でファイルの変更等を管理する。
  
• リモートリポジトリへ変更内容を反映させる
  ローカルリポジトリでの更新された内容を，リモートリポジトリに反映させる。
  これにより，共有するファイル類を更新することができる。
  

のように行う。

Gitの良い点

例えば「ある使用ライブラリを1.xから2.xにバージョンアップする」という作業を考えてみます。

作業タスクは，以下の様な感じになります。

1. 既存ライブラリの削除（1.xは削除して2.xにするために）
2. 2.xのライブラリをプロジェクトに取り込む
3. 1.xから2.xで変更となったAPIの反映
4. Licence表記の変更（必要があれば）

これらの変更作業は，それぞれ独立していると考えられる。（それぞれの作業にゴールがある）

これをSubversionで管理している場合は，すべての作業が間違いなく完了していないと共有リポジトリにはコミット出来ない。

この事は，以下のことを意味する。

• コミット前の動作確認で正しく動作しない場合，自分がどこで間違えたか分からない。
  
• ソフトウェアのコードレビューをする人は，すべての修正作業をまとめてレビューして検証する必要がある。
  

これが，もしローカルコミットが出来るとどうなるかというと，

1. 既存ライブラリの削除（1.xは削除して2.xにするために）
   ＜コミット1＞
2. 2.xのライブラリファイルをプロジェクトに取り込む
   ＜コミット2＞
3. 1.xから2.xで変更となったAPIの反映
   ＜コミット3＞
4. Licence表記の変更（必要があれば）
   ＜コミット4＞

それぞれの作業タスクで，差分を確認してコミットをすることが出来るようになる。
この段階では共有リポジトリへの反映はしていないため，他の開発者への影響は全くありません。

つまりローカルコミットがない場合と比べて，どのような変化が起こるかと言うと，

• コミット前の動作確認で正しく動作しない場合，コミット単位で間違いを探せる
  差分（diff）あるいは過去コミットのチェックアウトすることで確認できる。
  
• コードレビューをする人は，それぞれのコミット（独立した作業単位）でレビューして検証出来る
  作業単位でレビューできるので集中することができる。
  

のようになりSubversionを使った場合の問題が解決しています。

この構造を採用したバージョン管理がGitになる。ここがSubversionに比べてGitが優れている点になると思う。

履歴を管理するリポジトリ

リポジトリとは，ファイルやディレクトリの状態を記録する場所です。
保存された状態は，内容の変更履歴として格納されています。
変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで，そのディレクトリ内のファイルやディレクトリの変更履歴を記録することが出来ます。

リモートリポジトリとローカルリポジトリ

Gitのリポジトリには，リモートリポジトリとローカルリポジトリの2種類があります。

• リモートリポジトリ
  ファイルが共有できるファイルサーバー等に配置して，複数人でファイルを共有するためのリポジトリ。
  
• ローカルリポジトリ
  ユーザ一毎の利用のために，自分のPC上に配置するリポジトリ。
  

リポジトリをリモートとローカルの2種類に分けることで，普段の作業はローカルリポジトリ（ローカルリポジトリは自分のPCの任意のディレクトリに作成できる。）を使って全て自分のPC上で行うことが出来ます。
自分のローカルリポジトリで作業した内容をみんなと共有するために，リモートリポジトリにファイルをアップロードして共有・公開します。
また，リモートリポジトリを通して，他の人の作業内容を取得することが出来ます。

ワークディレクトリとインデックス

各個人が実際に作業をしているディレクトリのことを，Gitではワークディレクトリとかワークツリー''と言っている。

そして，リポジトリとワークツリーの間にはステージングとかインデックスと呼ばれているところがあります。
インデックスは，ローカルリポジトリにコミットする準備をするための場所になります。

Gitは，コミットを実行した時にワークツリーから直接ローカルリポジトリ内に状態を記録するのでなく，その間に設けられているインデックスの設定された状態を記録するように処理されます。
このため，コミットを使ってファイルの状態を記録するためには，まずインデックスにファイルを登録する必要があります。

このようにインデックスを間に入れることで，ワークツリー内の必要ないファイルを含めずにコミットを行ったり，ファイルの一部の変更だけをインデックスに登録してコミットすることが出来るようになります。