(第1回)やさしいGit(バージョン管理システム)の使い方講座

(第1回)やさしいGit(バージョン管理システム)の使い方講座

目次

はじめに
Gitの特徴
SourceTreeのダウンロード
リポジトリの作成
コミットしてみよう
ブランチの作成
次回予告

はじめに

プログラム開発にはかかせない、ソースコードを保管するためのバージョン管理システムには様々な種類が存在していますが、中でもGitなどは取り立てて有名なシステムの一つとなっています。当記事では、初めてバージョン管理システムを使用される方向けに、Gitを例とした基本的な管理方法などを説明していけたらと思います。
コマンドライン(コンソール)からGitコマンドを実行させる方法が主流かと思いますが、バージョン管理方法などの概念を分かりやすく説明するために、「Sourcetree」というGUIの操作でGitコマンドを実行できるツールを使用します。

Gitの特徴

Gitの長所を説明すると、大きな特徴として「分散型バージョン管理システム」であることが挙げられます。バージョン管理システムには大きく分けて「分散型」と「集中型」の2種類が存在します。

集中型」の有名な例には、オープンソースとして公開されているSVN(Subversion)、マイクロソフトのTFS(TFVC : Team Foundation Version Control)などが存在します。その特徴は、ネットワーク上の一つのリポジトリ(ソースコードや、その変更履歴が保管されている倉庫のようなもの)を複数人で使用することです。ソースコードの編集をする際は、共有のリポジトリからソースコードを持ってきて編集を行い、編集が完了したら直接共有リポジトリに変更を反映させます。

対する「分散型」の特徴は、「集中型」のようにリポジトリを1つに限定するのではなく、各自が自分のPC上にリポジトリを作成します。そのメリットとしては、ある程度作業が進んだ時点で親のリポジトリや他の開発者のリポジトリへの反映が可能、ローカルにリポジトリを作成するため、オフラインの作業が容易、などの柔軟性が主に挙げられます。また、万が一リポジトリのデータ消失などが発生しても、リポジトリが分散して存在していることにより、消失前のデータを復元できる可能性が高められます。

各自がローカルに作成したリポジトリを「ローカルリポジトリ」と呼ぶのに対し、ネットワーク上に存在している、メンバー間共有のリポジトリのことを「リモートリポジトリ(中央リポジトリ)」と呼びます。リモートリポジトリは、社内サーバー、もしくはGithubやBitbucketなどのホスティングサービス上に置かれ、複数人でソースコードを更新していく形になります。

SourceTreeのダウンロード

では、実際に以下の公式サイトよりダウンロードしてみます。
Source tree 公式サイト

※Ver.3.0以降ではBitbuketのアカウント作成が必須になるため、今回はSourceTree用の
アカウント作成のみで完結できるVer.2.7.6をダウンロードします

②インストール後、Github、Bitbucketなどのリモートサーバーの接続設定ができますが、今回は「セットアップをスキップ」をクリックします。(後ほど再設定可能です)

リポジトリの作成

リポジトリとは、ファイルそのものと、その過去の状態を記録できる保管庫のようなものです。冒頭で触れたように、各自が自分のパソコンに作成したリポジトリを「ローカルリポジトリ」と呼び、 ネットワーク上に存在する共有のリポジトリ を「リモートリポジトリ」と呼んでいます。今回の記事では、ローカルリポジトリの作成と更新方法に加え、基本的な操作について解説していきます。

では、早速自分のパソコン内にローカルリポジトリを作成していきたいと思います。

フォルダの作成

Sourcetree内の「ローカルリポジトリを作成」を選択します。選択後、作成するフォルダのパスとフォルダ名を入力する画面が表示されるので、任意の値を入力します。

作成ボタンをクリック後、指定した場所にフォルダが作成されました。

Sourcetreeの画面に戻ると、新しく行が追加されたことが確認できます。
この行をダブルクリックすることで、リポジトリの管理画面が開きます。

この時、Finder(Windowsではエクスプローラ)上で「隠しフォルダを表示する」に設定を変更すると、先ほど作成したフォルダ内に「.git」フォルダが作成されているのが確認できます。リポジトリに設定されたフォルダには隠しフォルダとして上記が作成され、過去のファイルやディレクトリの状態が蓄積されていくことになります。

コミットしてみよう

作成したリポジトリ内にファイルやディレクトリの追加・変更を記録(保存)する操作を指して、「コミット」と呼んでいます。
先ほど、リポジトリとして指定したフォルダにサンプルのテキストファイルを作成し、コミットの流れを確認していきます。

テキストファイルを作成したところでSourcetreeに戻ってみると、左側のバーにあるファイルステータスの横に「1」と表示されています。その下の履歴タブをクリックすると、下図のようにUncommitted changesと表示されていますが、これはリポジトリ内で行った変更がコミットされていない=まだリポジトリに保存されていないことを表しています。

対象のファイルを変更しただけではリポジトリに新たなバージョンとして変更が記録されないため、コミットを行う必要があります。

リポジトリへ新しくコミットする際は、まずはステージングエリアと呼ばれる、コミットさせたいファイルを置いておくためのエリアにファイルを移動させます。デフォルトでステージエリアが表示されていない場合は、画面中央のタブから「ステージビューを分割する」を選択します。

上記の操作により出現した、「Indexにステージしたファイル」と表示されているスペースがステージングエリアにあたり、その右側には選択したファイルの内容が表示されます。その下にある、コミットしたいファイル「sample.txt」にチェックを入れると、自動的にステージングエリアへファイルが移動します。これでコミットの準備が完了したので、左上のコミットボタンをクリックします。

コミットの内容を入力する画面が出てくるので、変更内容等を入力し、右下のコミットボタンをクリックします。ここでは、「早口言葉①」としてみます。

Uncommitted changesが消え、先ほど入力したコミットメッセージが表示されていることが確認できます。このコミットにより、リポジトリ内に新しいバージョンが記録されました。
ファイルに対して行った変更などを最終的に取捨選択し、リポジトリへ反映させたいものだけを選択(ステージ)、最新版として保管することができます。最終的にリモートリポジトリへ変更を反映させるまで、ローカル上で自由に作業が行えます。

では、先ほどのテキストファイルに更に変更を加えてみます。テキストファイルに文章を追記し、保存するとまた新たにUncommitted changesが表示されました。赤枠内の左にあるグラフをみると、ツリーのようなものが出来ていることが確認できます。このツリー状のグラフについては、最後に簡単に図解いたします。

先ほど同様に、対象のファイルをステージングエリアに移動させ、左上のコミットをクリックします。下図のようにコミットの内容を入力する欄が表示されるので、変更内容が分かるメッセージを入力し、今度は右下のコミットボタンをクリックします。(ここでは早口言葉②としています。)

2回目のコミットにより、1回目に作成したリポジトリの上に線が伸びる形で新しいリポジトリが作成されました。上から順に、更新日付の新しい順になっています。

この時、コミットメッセージの左側に表示されている「master」について簡単に説明します。リポジトリに最初にコミットしたバージョンは、自動的に「master」に分類されます。

「master」を1つの大きな木の幹としたときに、その幹から枝分かれするように、並行して作業ファイルを作成していくことブランチと呼んでいます。(枝、分岐を意味するbranchから来ており、ブランチをきる、などと表現されます)

上の図では、まだ枝分かれして作業が行われていないため、「masterブランチ」という木の幹だけが存在している形になります。基本的にmasterブランチの流れにいるファイルは公開可能な完成版を指し、masterブランチのソースコードに機能追加を行う際は、新しく木の枝を派生させ、変更したソースコードを最終的にmasterブランチにマージ(合流)させることで、機能追加や仕様変更を並行して行っていきます。

ブランチのメリットは、
・マージ前のレビューなどを徹底することで、masterブランチに修正途中の中途半端なコードが含まれるのを防げる
・バージョン毎の修正範囲が明確になりやすく、後から特定のバージョンへの切り戻しが容易になる


などがあげられます。ただ、複数人で作業をする場合、それぞれの担当範囲を明確にしておかなければ、互いの作業範囲が被って競合が発生してしまう可能性が高くなるため、どういう修正単位でブランチをきるかには注力が必要かもしれません。

ブランチの作成

では、最後に新しいブランチを作成してみます。現在自分がいるブランチは左側のバーで太字に表示されています。この状態で上部のブランチをクリックします。

新規ブランチ欄に任意の名前を入力し、「ブランチを作成」をクリックします。

新しく「sub」ブランチが追加され、画面左側に表示されているブランチの欄にも「sub」が追加されたのが確認出来ます。また、今度は「sub」が太字で表記されていることから、mainブランチから移動(チェックアウト)し、subブランチが現在位置となっています。

「sub」ブランチに新しくコミットするため、テキストファイルに追記してみます。

リポジトリ内のテキストファイルを更新し、subブランチ上で再びコミットすると下図の状態になりました。(コミットメッセージは早口言葉③としています。)
先ほどと比較すると、subがmasterの1つ先に移動したのが確認出来ます。新たに作成したsubブランチ上でリポジトリにコミットしたことで、masterブランチから枝分かれする形でsubブランチが保存されました。

先ほどと比較すると、subがmasterの1つ先に移動したのが確認出来ます。新たに作成したsubブランチ上でリポジトリにコミットしたことで、masterブランチから枝分かれする形でsubブランチが保存されました。

では、この変更をmainブランチにも反映させ、subを再びmainブランチに合流させようと思います。
左サイドバー内のmasterをダブルクリックすることで、再びmasterブランチに移動することができます。この状態でマージさせたい一番上の行で右クリックし、マージを選択します。

マージしても問題ないか確認するダイアログが表示されるので、OKを選択するとマージが実行されます。すると、再びmasterとsubが横並びに表示されました。ここで右下のファイルの内容を確認すると、subブランチの変更がmasterブランチにも反映されていることが確認できます。

ソースコードを編集する毎に、コミット、ブランチ、マージなどを繰り返していくことで、masterブランチに完成品が出来上がっていきます。

今まで行ったコミット・ブランチ・マージの流れを簡単に図解すると、下図のようになります。最後のマージによって、subブランチとmasterブランチの枝が合流されました。

次回予告

以上が、gitなどのバージョン管理システムにおけるコミット、ブランチ、マージの基本的な考え方になります。今までの流れは自分のパソコン内のリポジトリ(ローカルリポジトリ)内の操作のため、次回はネットワーク上に存在するリポジトリ(リモートリポジトリ)への操作を解説してみようと思います。