裏紙に書く程度の内容

Gitとは - Git入門

Git入門の第1回目です。

まずはGITとは何ぞや?というところを確認しておきましょう。

Git,VCSとは

Gitとは、VCS(Version Control System、日本語で「バージョン管理システム」)の一つです。

他に有名なVCSとして、ApacheのSubversion(SVN)や、MicrosoftのVisual SourceSafe(VSS)等がありますね。

昨今のソフトウェア開発現場では何かしらのVCSを導入してソースコード管理をしている場合がほとんどです。

使っていない現場は・・・地獄そのものとなります。

なぜVCSが必要なのか?

ソフトウェアの開発に携わっている人ならVCSの必要性は既にご存知かと思います。

ここではこれから開発に携わるという人向けの説明となります。

VCSがない場合

VCSを使わない場合、ソースコードはどのように管理するのでしょうか?

まず、誤操作や不慮の事故でソースコードが消えてしまわないよう、”バックアップ”が必要になります。

日々の作業で作成したソースコードを所定のファイルサーバ等に保管します。

複数人で開発をする場合はその所定のファイルサーバ内のソースコードを”最新”とみなし、ここから作業対象のファイルを取得・編集してまた元の位置に保管します。

ここで極めて重要になってくるのが、編集時のルール作りです。

変更箇所の把握が大変

AさんとBさんが同じファイルを編集した場合、マージ(AさんのファイルとBさんのファイルを合体させる作業)が必要になります。
この時、マージ作業する人はAさん、Bさん双方の修正箇所を知っておかなければなりません。

さらに、マージ作業中にCさんが同じファイルを編集していたら・・・。ということが起こると変更箇所の把握だけでも非常に面倒な作業になってきます。

これを避けるために「同一ファイルは複数人で同時に編集するのは禁止」とルールを設けることもあるでしょう。

また、オブジェクト指向のプログラム言語においては、1つの作業(とある機能の実装や、バグの修正とか)をするためには複数ファイルを編集することが多々あります。

前述「同一ファイル編集禁止」ルールを適用するとなると、開発チームの人数が多ければ多いほど待ち時間が多くなりますね。これでは仕事にならないのでやっぱりこのルールはいただけません。

となるとソースコードの管理のために、”いつ、だれが、どのファイルのどの箇所を修正した、編集後ファイルはここからここまでマージ済み”等、全てを把握する必要があり、そのためには全開発メンバーが一定のルールで「この作業のために、このファイルのここを修正しました。」という意思表示を行わなければなりません。

本当に最新か?

前述のとおり完璧且つ明確なルールを設けて開発をスタートさせても、ヒューマンエラーは必ずついて回ります。
「とある作業でファイルいくつかを修正したんだけど、1ファイル通知するのを忘れた。」とか。

あるいは、Aさんがサーバから最新のソースコードを持ってくるのを忘れてしまい、編集をした。
その後、マージ作業者が「今日はAさん以外そのソースコードを編集しなかったのでAさんのファイルをそのまま最新とした」場合、それ以前の修正はすべて吹っ飛んだり。

元に戻せない

他の箇所への悪影響や、仮で作ってみた機能等、変更をなかったことにしたいケースが開発途中ではよく出てきます。

日々全てのバックアップを取っていれば、元に戻すことも可能ですが、チーム全体の作業を元に戻すわけにはいきませんね。
となると必要な箇所だけ戻すという、逆マージする作業が発生したりもします。

そこでVCSの出番

ここまでで、ソース管理を手動でするには完璧なルール管理担当者、そして絶対ミスらない・ルールを破らないということが必要になります。

特に3番目の絶対ミスらないというのは人が手作業でやることですのでもはやムリ!

となるとミスらないように何かしらの『ツール』が必要と考えるのは必然ですね。

その『ツール』こそがVCSというわけです。

開発者が1人の場合はいらない?

前述では複数人の開発の例をあげましたが、開発者が1だけの場合はどうでしょうか?

マージ作業は不要となりますが、ソースを元に戻す必要性を考えると適宜バックアップが必要になります。
全てのバックアップにバージョン(又はバックアップの日時)を振っていって、「どの作業のバックアップがバージョン○○」といった管理は必要になってきます。

或いは、既にサービスインしているシステムを例に挙げると、

『追加機能を開発中にバグの報告が上がってきた。運用中のシステムなので急いで直さないといけない。』

といった事象が発生したとします。

開発者は

  1. 現在の作業を一旦止めて、
  2. 運用中バージョンのソースコードを持ってきて、
  3. バグを修正、
  4. 修正履歴を残し、
  5. バグ修正分を現在作業中ソースコードへマージ

というかなり面倒で手間のかかる作業を行わなければなりません。

また、運用中なのでかなり焦ることも考えられるでしょう。
この状況下ではなにがしかのミスが発生する可能性も高くなります。

そこでやはり『ツール』は必要と考え、VCSはこの目的に合っているものです。

開発者が1人だけの場合でもVCSは導入すべきツールです。

VCSのいろいろ

代表的なVCSは以下です。

name Type memo
Git 分散型 Linuxのコード管理のために作られた。現在の主流
Subversion 集中型 CVSの改良版。1世代前では主流
CVS 集中型
Mercurial 分散型
VSS 集中型

Typeの分散・集中型というのはリポジトリが1極集中か複数あるかの違いです。

一昔前はどこもかしこもSubversionかVSSを使っていましたが、現在はGitやMercurial等、分散型が主流になってきています。

これからVCS導入してみようって人はとりあえず一番使われているGitにすれば間違いないでしょう。


とりあえず今回はここまで。

Gitに限らずバージョン管理システムの必要性はは分かっていただけたんじゃないでしょうか。

広告
Index