GitHub公式クライアントでだれでも簡単GitHubライフをはじめよう

Gitとは

Git は、VCS(Version Control System)、あるいは、SCM(Software Configuration Management)などと呼ばれるソフトウェアの一種です。 同種のソフトウェアとして、 Mercurial や、 Subversion といったものが広く使われています。これらは、いずれもフリーソフトウェアです。

Gitを使用すると、ディレクトリに含まれるファイルのスナップショットを、好きなときに好きなだけ保存しておくことができます。 スナップショットを保存してく場所のことをリポジトリと呼びます。 Gitを使えば、システム上にある任意のディレクトリをリポジトリ化できます。¹ 実際の使用では、プロジェクトごと(例えば、ウェブサイトに関連するファイル一式など)にリポジトリを作成する場合が多いと思います。

Gitではディレクトリの内容を「スナップショット」として積み重ねていく

リポジトリ上に保存されたスナップショットは、いつでも好きなときに復元して、現在のディレクトリに置かれているファイルセットを切り替えることができます。

Gitは行指向のツールです。つまり、Gitのファイル管理機能のほとんどは、テキストファイルを対象としています。 リポジトリ内にPSDやJPEGなどのバイナリファイル²を格納することもできますが、スナップショット間の差分を確認したり、異なるスナップショットを統合するなどの便利な機能は、それらに対しては使えません。

ちなみに、Gitクライアントのオリジナルのバージョンは、コマンドラインで操作するツールです。 ですが、オリジナル版以外にも、いくつものGUIバージョンが開発されています。GitHub Desktopも数あるGUI版クライアントのうちのひとつです。

GitHubとは

GitHubのキモかわいいマスコットキャラクターOctocat君

GitHubは、Gitで管理しているリポジトリをインターネット上で公開するためのウェブサービスです。³

GitHubでは、リポジトリのホスティング以外にも、Issue管理やWikiといったプロジェクト運営のためのいくつかの機能が使えます。 また、後述のプルリクエスト機能により、公開されているプロジェクトに気軽に貢献できるのが最大の特徴です。

GitHub Desktopの特徴

さきほど述べたように、Mac/Windows用ともに、 いくつものGUI版Gitクライアント があります。 GitHub Desktopの特徴としては、

• コマンドライン版と比べ、大幅に機能が制限されている。
• GitHubと連携するための機能が実装されている。
• Mac/Windows用があり、ほとんど同じUIを提供している。

といったものが挙げられます。

GitHub Desktopは、コマンドライン版ほどパワフルな管理機能は備えていませんが、日々の業務で使うのに必要な最低限の機能は備えています。機能が制限されているぶん、ときに難解と言われるGitの導入障壁がいくぶん軽減されることが期待できます。⁴

また、GitHubアカウントと連動し、GitHub上で自分と関連付けられているリポジトリを一覧表示したり、プルリクエストといったGitHub特有の機能を直接使うことができるのは、GitHub Desktopならではと言えるでしょう。 Windows版では、GitHub Desktopのインストール時に、コマンドライン版(GitHub Shell)もいっしょに導入できます。Mac OS Xには最初からgitがインストールされています。

Mac/Windows両対応なのも人に使い方を説明するときには重要です。 なお、以降では、Mac版のスクリーンショットを使用します。Windows版でも、若干の見た目の違いはあるものの、UIのレイアウトや機能などはほとんど同じですので、支障はないかと思います。

なお、この記事で使用しているクライアントのバージョンは、

• Mac版 Beset by Computers (220)
• Windows版 Proctional Fungramming (3.0.17.0)

です。

セットアップ

アプリケーションをダウンロードしたら、まずはじめに、GitHub DesktopにGitHubのアカウント情報を登録する必要があります。 アカウント情報の扱いについてはMacとWindowsで若干違いがあり、Macでは、キーチェーンにIDとパスワードが保存されます。 Windowsでは、初回の設定時に、SSHのキーペアが自動的に生成され、GitHubに登録されます。

GitHubでのワークフロー

それでは、実際の使い方の説明に入っていきましょう。 GitHubで一般に公開されているプロジェクト(リポジトリ)に貢献するためのおおまかなフローは次のとおりです。 ⁵

1. フォークする
2. リポジトリをクローンする
3. ブランチを作成する
4. 機能追加あるいはバグ修正をコミットする
5. プッシュする
6. プルリクエストを作成する

GitHubでのワークフロー

以下、順を追って説明していきます。

1.フォークする

フォークとは、GitHub上のプロジェクトを自分のアカウントにインポートすることです。 フォークされたプロジェクトは、自分のアカウントに完全にコピーされ、元のプロジェクトに直接影響を与えることはないので、自分の好きに改変することができます。 自分がオーナーでない、またはコラボレーターに入っていないGitHub上のプロジェクトに貢献するためには、まずはフォークをする必要があります。

まずは、フォークしたいプロジェクトのGitHub上のページをブラウザで開きましょう。

フォークボタンの場所

ページ右上あたりにある“Fork”と書かれたボタンを押せばフォークできます。

2.リポジトリをクローンする

クローンとは、読んで字のごとく、リポジトリを複製することです。 リポジトリをクローンすると、クローンした(自分の手元にある)リポジトリには、どこからクローンしてきたかという情報が記録されます。 クローンされた元のことをoriginと言います。

クローンボタンの場所

フォークしたプロジェクトのページを表示して、“Download Zip” の左隣にあるボタンを押しましょう。自分のローカル環境にリポジトリをクローンできます。

GitHub Desktopからクローンする

または、GitHub Desktopの左上にある+ボタンからクローンしてもかまいません。

GitHub Desktopでは、GitHubからリポジトリをクローンする以外にも、既存のローカルリポジトリ(他のソフトウェアで作成したものなど)をインポートしたり、新規にリポジトリを作成することもできます。

3.ブランチを作成する

Gitのファイル管理では、スナップショットを任意のタイミングで保存していき、履歴を形作ります。 なにもしなければ、それは一本のまっすぐな更新履歴という形になりますが、ブランチを追加する⁶ことで、履歴を分岐させることができます。 作成したブランチは、いつでも自由に切り替えることができて、それに追随して、実際のディレクトリの中身も入れ替わります。Gitでは、ブランチの作成や切り替えは、非常に高速に行うことができます。⁷ リポジトリを新規に作成すると、masterと呼ばれるデフォルトのブランチがひとつ自動的に作成されます。

ブランチでバージョンを「派生」させる

プロダクトに新しい機能を実装したり⁸バグフィックスをしたりするときには、その作業用のブランチを作成します。ブランチの名前は、これから行おうとしている作業を適切に表した名前にしましょう。たとえば、サイトにサイドバーを追加しようとしているなら、add-sidebarのようなブランチ名にします。

ブランチボタンの場所

GitHub Desktopでブランチを作成するには、ウィンドウ上部にあるブランチ追加ボタンを押します。Fromで、どのブランチの先端から新たなブランチを派生させるかを指定します。どのブランチから派生させるべきかは、プロジェクトの運用形態により異なりますが、masterやdevelopといった名前のブランチから派生させることが多いでしょう。以降、masterからブランチを作成することを前提として記述しますが、適宜読み替えてください。

4.機能追加あるいはバグ修正をコミットする

ブランチを作成したら、実際にファイルを更新していきます。 ディレクトリのスナップショットをリポジトリに追加することを コミットする と言います。あるいは、スナップショットに加える変更全体を指して コミット と言ったりもします。

リポジトリ化したディレクトリ内にファイルを追加したり、あるいはリポジトリに含まれるファイルを更新・削除したりすると、下記の図のように変更点が表示されます。

コミットの差分

ファイル名の左側についているチェックボックスは、コミットにそのファイルを含めるかどうかを表しています。チェックをはずすと、そのファイルに対して加えた変更は、コミットから除外されます。右側のビューでの赤い行は削除される行、緑の行は追加される行を示しています。 変更内容を確認の上、その内容でスナップショットを保存していいと判断したら、コミットログを記入してコミットボタンを押します。

コミットするときは、変更内容の説明を記入する

コミットをする際には、コミットログとして、最低限1行の要約を記入する必要があります。変更内容を端的に表した文面を考えましょう。

もしコミットした後にコミットログや変更自体の誤りに気付いたら、直前のコミットに限ってアンドゥをすることができます。 “Undo”ボタンを押してから、再度コミットをし直しましょう。⁹

ひとつのコミットで、あまり大きな修正をするのは避けましょう。大き過ぎるコミットがひとつあるよりは、細かいコミットがたくさんあるほうがいいです。 その上で、できればひとつのコミットが、論理的な修正単位と対応するようにし、できれば、どのコミットの時点でもコードが、最低限の基準を満たす¹⁰ようにしておくのが望ましいでしょう。

5.プッシュする

実装が完了して、すべてコミットできたら、ローカルで作成したブランチをGitHubに送信しましょう。 これを プッシュ と言います。

Publishボタンの場所

対象ブランチの右側にある“Publish”ボタンを押せば、ブランチをプッシュできます。

Syncボタンの場所

一度プッシュすると“Publish”ボタンが“Sync”ボタンに変化します。プッシュ済みのブランチにコミットを追加して、再度GitHubに送信したい場合は、“Sync”ボタンを押せばOKです。

6.プルリクエストを作成する

いよいよ最後、 プルリクエスト です。 プルリクエストとは、フォーク元のプロジェクトに対して、ブランチで追加したコミットを取り込んで欲しいという要求を送ることです。 ちなみに、フォーク元のプロジェクトのことをupstreamと呼んだりします。

プルリクエストを送りたいブランチを選択した状態で、ウィンドウ右上の“Pull Request”ボタンを押すと、以下のようにプルリクエストペインが表示されます。

プルリクエストボタンの場所

2本の線(コミットログ)が表示されており、下側は現在選択しているローカルのブランチ、上側がマージ先のブランチを表しています。 マージ先のブランチは選択可能です。 これらが適切であることを確認し、必要に応じてコメントを記入したら、プルリクエストペインの下部にある “Send Pull Request”ボタンを押しましょう。

必要に応じてプルリクエストのマージ先を選択する

これで、プルリクエストの作成ができました。 プルリクエストを作成すると、“Pull Request”ボタンの表示が変化し、このボタンを押すとブラウザ上でプルリクエストを確認できます。

プルリクエストの作成ができたら、あとは、upstreamのプロジェクトオーナーによるレビューを待ちます。 レビューした結果、問題がなければ、無事あなたのプルリクエストは、取り込まれることでしょう。 ブランチに含まれるコミットを、派生元に取り込むことを マージする と言います。

もしレビューの結果、問題箇所を指摘された場合は、その点を修正して、再度コミット・プッシュ(Sync)しましょう。 すると、プルリクエスト上にコミットが積み重なっていきます。

マージされれば、プロジェクトへの貢献作業は一段落です。おつかれさまでした。

GitHubでのワークフロー(2回目以降)

さて、最初のプルリクエストはマージされました。その後、プロジェクトに対してさらなる貢献をしたくなったとしましょう。 この場合には、すでにフォークとクローンは済んでいるので、1回目とはすこしフローが異なります。

1. upstreamから更新を取得する
2. ブランチを作成する
3. 機能追加あるいはバグ修正をコミットする
4. プッシュする
5. プルリクエストを作成する

GitHubでのワークフロー(2回目以降)

1.upstreamから更新を取得する

自分のリポジトリとは独立して、upstreamのほうでも、日々刻々と更新が積み重ねられているため、upstreamのmasterと、自分のリポジトリのmasterの間でズレが生じていきます。作業を開始する前に、必ず、最新の更新を手元のリポジトリに取り込みましょう。GitHub Desktopでは、以前のGitHub for Mac/Windowsと比べて、upstreamからの更新の取り込みが非常に簡単になりました。

まず、masterブランチを選択します。upstreamのmasterではなく、ローカルのmasterを選択する必要があるので注意してください(XXXXX/masterでなく、ただのmasterを選択する)。 upstreamに更新がある場合には、“Update from XXXXX/master”というボタンが押せる状態になっています。このボタンを押すと、upstreamでの更新をローカルに取り込んでマージすることができます。

クローン元から最新の状態を取得する

これで、ローカルのmasterが、upstreamのmasterと同期されました。

コンフリクトの解消

プルリクエストを出したときに、GitHubウェブサイトのプルリクエスト画面上で、次の図のように、左側のマージアイコンが灰色で表示され、自動的にマージができない旨のメッセージがでる場合があります。これは、あなたのブランチを取り込むときに コンフリクト が発生することを示しています。

コンフリクトが発生しているとマージできない

GitHub Desktopであれば、プルリクエストペインに次のように警告が表示されます。

GitHub Desktopでのコンフリクト表示。

基本的に、Gitはブランチのマージを自動で行ってくれますが、マージ元とマージ先で同じファイルの同じ箇所に対して同時に編集がなされていると、機械的にマージできない場合があります。場合によっては、upstreamのオーナーがコンフリクトを解消してくれることもあるかもしれんが、基本的には、プルリクエストを出す側がコンフリクトを解消したほうが親切でしょう。

コンフリクトが発生したということは、ブランチを作成した後に、upstreamでmasterに対してコミットが追加されたことを示しています。

自分の作業と並行して、upstreamにも変更が加えられている場合がある

そのため、まずは、ローカルのブランチをupstreamと同期させる必要があります。 さきほどのupstreamからmasterへの更新取得と同じ要領で更新を取得します。 対象のブランチを選択した上で、“Update from XXXXX/master”ボタンを押せばOKです。

Upstreamからブランチに更新を取り込む

するとコンフリクトが生じるはずなので、更新取得後、マージの途中で止まります。

ファイルにコンフリクトが発生していることを示すメッセージ

コンフリクトが発生したファイルを選択すると、上図のようなメッセージが表示されます。 該当ファイルをテキストエディタで開くと、次の例のように、衝突した部分が<<<<<と>>>>>で囲まれた状態になります。

          <div class="col-sm-6 col-md-3">
            <a href="">
            <div class="thumbnail">
              <!-- ここに自分の写真を追加 -->
              <img src="http://tai2.net/img/tai2.jpg" />
              <div class="caption">
                <h3>
                  <span>Name</span>
                  Taiju Muto(tai2)
                </h3>
                <h4>
                  <span>Job</span>
<<<<<<< HEAD
                  Sniper
=======
                  Chef
>>>>>>> master
                </h4>
              </div>
            </div>
            </a>
      </div>

HEADから=====までの部分が自分のブランチで加えた変更を、=====からmasterまでの部分が、upstreamで加えられた変更を表しています。 正しい編集内容に自分で編集して、ファイルを保存しましょう。 そして、通常の変更と同様にコミットします。コミットログには、自動的にこのコミットがマージ時にコンフリクトを解消したものである旨が記入されます。コミットができたら、GitHubにプッシュ(Sync)しましょう。 自動的にマージできる状態になっていれば、最初のプルリクエストのようにアイコンが緑色で表示されているはずです。

自分がオーナーまたはコラボレーターに指定されている場合のワークフロー

自分自身がオーナーである場合、またはコラボラーターに指定されている場合には、リポジトリに直接プッシュする権限があります。 そのため、これまで説明したフローよりも簡単で、最初にプロジェクトをフォークする必要はありませんし、 また、プルリクエストを作成せずに直接masterに変更を加えることも可能です。 ただし複数人で共同作業をする場合には、プルリクエストを利用すると、メンバーにコードレビューをしてもらうときに便利です。

まとめ

本稿では、Gitの基本概念について述べました。また、GitHub Desktopを使用して、プロジェクトをフォークし、ローカルマシンで修正を加えて、プルリクエストを作成するまでの流れをひととおり説明しました。

更新履歴

• 2015/2/26 作成
• 2016/4/28 GitHub Desktopに合わせて改訂。