現在BOOTHにてSteins;Git電子書籍(PDF)版のダウンロード販売をしています。紙の書籍版は「入荷お知らせメールを受け取る」を押していただけると販売開始するかもしれません。

この書籍のハッシュタグは #SteinsGit です。

リポジトリは o2project/steins-git です。

当サイトでは、内容の改善などを目的として、Google アナリティクスにより、アクセス情報を匿名のトラフィックデータという形で収集し、解析しています。データの収集を無効化したい場合はこちらのリンクより無効にする事ができます。


この書籍はSteins;Gateのネタバレを含んでいます。

当サイトはニトロプラスの許可の上でニトロプラスの著作素材を引用しております。これらは他への転載を禁じます。


はじめに

Git のロゴ

本書は「Git の使い方を Steins;Gate の世界観を通して説明する」事を目的にして執筆しました。

対象読者として想定しているのは「Steins;Gate のアニメを全話、もしくはゲームで全てのエンディングを見た」人となります。

その対象読者が「Git に触れた事が無い、もしくは触り始めたばかりという人が、使い方を知るきっかけになる」事を本書の目標としています。

そのため、Git の全ての機能の説明をしません。自分が普段使う事が多い機能を中心に書いています。

謝辞

@kyo_ago[1] の下記のツイートにより、本書を書こうと思いました[2]

結局「シュタゲで覚えるgit」って誰も書かなかったんですか? 2013年12月19日[3]

@kyo_ago には Twitter 上で様々な助言をいただいたり、@watilde[4] を交えてレビュー会というのをしていただきました。

Gitter[5] というチャットサービス上では、yosiwo[6] さんに構成について助言をもらいました。

また @GeckoTang[7] には誤字の指摘をいただきました。

「シュタゲで分かるGit」をテーマにした「Steins;Git」という薄い本をC86(コミックマーケット86)で頒布します[8]という記事を公開した際、期待や実際に欲しいといった声をあげてくださった皆さんには、執筆を頑張る気力をもらいました。

また、進捗管理・イラスト発注・印刷業者への確認・本書のレビューと、さまざまな作業を担ってくれた fruitsnoodle[9] と、表紙と各章のイラストを描いた GiantRobot[10] さんには非常に助けられました。

本当にありがとうございます。

本書の構成

本書は全三章とあとがきから成り立っています。

  1. 第一章では、バージョン管理とは何かという事を説明し、その中で Git の特徴について書いていきます。

  2. 第二章では、バージョン管理システムの中でも、なぜ Git を使うのかというのを利点を提示して説明します。

  3. 第三章では、自分が Git でよく使う機能について、SourceTree と GitHub for Windows (Mac) というソフトウェアを用いて説明します。

  4. あとがきでは、ラボメン内で使うなど Git を複数人で使用する際に、その助けとなるサービスを紹介します。また、本書を書くにあたって参照したサイトや書籍を紹介します。

1. 第一章 - 改変管理のデュバス

Gitに触れる前に、バージョン管理について説明します。

バージョン管理は「あるプロジェクト内でファイルの変更履歴を記録しておく」事です。

変更履歴とは「いつ、何が、誰によって変更された」というのを指し示します。ゲームのセーブデータみたいだなと思った人はだいたい合っています。

バージョン管理には、Git や Subversion(SVN) といった、バージョン管理のために作られたものを使う手法から、単純にファイル名を変更していくだけの手軽なものまであります。

では、まずは「単純にファイル名を変更していくだけの手軽な方法」について説明していきます。

1.1. 手軽なバージョン管理

手軽かつ、よく使われるバージョン管理の手法として「ファイルに変更をするたびに、ファイルの名前を変更していく」というものがあります。

Steins;Gate で例えると「各章のフォーントリガーがキーになるところでデータをセーブしておく」という手法を使った事がある人はいると思います。

Steins;Gate ロード画面

このバージョン管理手法の利点としては「手軽である」という事です。

ファイルを変更するたびに、エクスプローラーや Finder 上でファイルを選択した状態で Windows では F2 Mac では Enter を押して名前を編集する事により、手軽にかつ PC を初めて起動した直後でも、ファイルのバージョン管理をおこなう事ができます。

しかし、ファイル名を変更するだけのバージョン管理には、問題点が思いつく限りでも三つあります。それらの問題点について一つずつ詳細に書いていきます。

1.1.1. どのファイルを更新すればいいのか分からなくなる

例えば、未来ガジェットのアイデアをひらめいてメモしたいとき、以下の画像で示しているようなファイル管理方法の場合だと、岡部は「はて…どれに書き込めばよかったかな」と困るでしょう。

未来ガジェットのアイデアをあちこちに書いてしまった例

またこの場合「最終版」という名前が付いたファイルにひらめいたアイデアを書き込んだものの、実は「最新」と書かれているほうが新しかった…という事が起こる可能性が大いにあります。

1.1.2. 内容を前のものに戻しづらい、または戻せない

岡部がひらめいたアイデアを「最終版」と書かれているファイルに書き込んだ際、それが最新ではないと分かり、元のファイルの状態に戻したいと思いました。

しかし、元の状態がどんなものだったか岡部は思い出せず、残しておきたかったアイデアまで削除してしまったり、追記したアイデアを完全に消せていなかったという事が起こりました。

この事象は岡部だけではなく、ファイル名を変更するバージョン管理をしている人全員に起こりえる事です。

これを Steins;Gate のゲームシステムで例えて言うと、データをセーブする場所を間違えて、消したくないセーブデータが消えたという事になります。

このような経験をした事がある人はいると思います。実際に自分も各ヒロインの個別エンディングを見るために残しておいたデータに、誤って別のデータを上書きしてしまい、再度やり直したという事がありました。地味に辛かったです。

1.1.3. 多人数での編集がほぼ不可能

岡部が、ひらめいたアイデアを書いたファイルをネットワーク上の共有のディレクトリに保存していたとします。

それを紅莉栖が見て、あれこれ書いて保存したと思った矢先、岡部が、紅莉栖が変更する前の状態で共有ディレクトリに保存していたファイルを開いてしまい、新たなアイデアを書いて保存してしまいました。

そうした結果、紅莉栖が編集したところは全て消え、岡部が変更したところしか反映されていない……という事になります。おそらくこの事で二人は口喧嘩するでしょう。

1.2. 分散型バージョン管理システム「Git」について

このように「ファイル名を変更するだけのバージョン管理」では、多人数でファイルを編集したいときに困る事になります。

また、内容を前のものに戻しづらい・戻せないという事が起こりやすいため、紅莉栖と岡部で作業したところが被ってしまい片方の変更点が消えた結果、どちらかが作業をやり直し……という事が起きます。

そこで、この書籍のテーマである「Git」が登場します。「Git」は「分散型バージョン管理システム」といわれるものです。

1.2.1. Gitの概要

上記でも書きましたが「Git」は「分散型バージョン管理システム」の一つです。他の分散型バージョン管理システムとして「Mercurial」「Bazaar」などがありますが、この書籍では特に触れません。

Git の読み方は「ギット」です。[11]イギリス英語のスラングで「バカ」「卑劣な」という意味があるそうです。なぜこの名前が付いたかはWikipedia[12] や、Git FAQ (英語)[13] を見てみてください。

Git は「リポジトリ」という「ファイルのスナップショット[14]が保管されている場所」があります。

スナップショットを保存する方法ですが、Git には「コミット[15]」という「スナップショットを任意のタイミングで保存する機能」があります。その機能を使う事により、自分がした作業を記録する事ができます。

この「コミット」ですが、Steins;Gate のゲームシステムで例えると「セーブ」と言えます。そして「セーブデータ」が「リポジトリ」です。

ただし Git の場合は、セーブデータの任意の場所に戻る事ができます。それは「特定のエンディングに進もうとしてセーブしておいたデータに、誤って別のデータをセーブしてしまっても元に戻せる」という事を意味します。

また Git で他の人と作業内容を共有したいという場合は、ネットワーク上に共有リポジトリを用意しておき、そこへ自分の作業内容を送信します。

作業内容の送信をする機能を「プッシュ[16]」と言います。

1.2.2. Gitの利点

Git の概要でも書きましたが、作業した内容を作業前の状態に戻したいといったときでも「チェックアウト[17]」や「リバート[18]」という機能を使えば、手軽に戻す事ができます。

これによりファイルを編集する際に、ファイル名に日付などを追加してからコピーという事をしなくて済むので、編集すべきファイルがどれなのか分からなくなる問題が無くなります。

また、多人数での編集も「プル[19]」という「自分の PC 上のリポジトリに、ネットワーク上にあるリポジトリの最新の内容を反映する機能」を使う事により、他の人が変更した点も取り込めます。

なので、同じファイルを編集してしまったために、どちらかの編集内容が消えてしまうという事が少なくなります。これで岡部と紅莉栖も喧嘩しなくなるでしょう。

2. 第二章 - 一問一答のコンクルージョン

バージョン管理システムには「分散型バージョン管理システム」といわれる Git (とその他)以外にも「集中型バージョン管理システム」といわれる Subversion (SVN) などがあります。

集中型バージョン管理システムより、なぜ分散型バージョン管理システムの Git を使ったほうがいいのか、メリットを解説していきます。

2.1. 流行っている

SVN と比較すると、Git は流行しています。つまり、それだけ皆が使いノウハウが出やすい状況にあります。

といっても、言葉だけでは説得力がありません。なので、流行している事を示すデータをいくつか紹介します。なお、これから出てくるスクリーンショットは2014年8月3日に撮られたものです。

はじめに Google トレンドで日本における Git・SVN・Subversion の人気度の動向を調べた結果[20]です。

ここでは Git が登場した2005年4月から2014年7月までのグラフを掲載していますが、2013年あたりから SVN と Git の人気度が逆転し、Git は今なお右肩上がりになっています。今後もこの傾向は変わらないと考えられます。

Googleトレンド

次に Qiita[21] という、プログラミングやソフトウェア開発のときに使うツールなどの情報を投稿するサイトがあるのですが、そこで SVN と Subversion を検索した結果[22][23]が以下の通りになります。

QiitaでSVNを検索した結果

次に Git を検索した結果[24]です。SVN と比べ、まさにケタ違いの投稿数とフォロワー(タグの新着の投稿を追っている人達)となります。

QiitaでGitを検索した結果

最後に Stack Overflow[25]という、プログラミングやソフトウェア開発のときに使うツールなどで分からないところを聞く掲示板のようなサイトがあるのですが、そこでタグ検索[26]で SVN を検索した結果が以下の通りになります。

Stack Overflow で SVN を検索した結果

次に Git を検索した結果です。SVN に比べ、タグが付けられた数が二倍以上となっています。

Stack Overflow で Git を検索した結果

以上の事から、Git は SVN に比べて流行っていると言えます。

2.2. ネットワーク接続がいらない

Git はネットワーク上にあるリポジトリを使わなかったり、もし使っていたとしても自分の手元で作業内容を記録する時はネットワークの接続は必要ありません。

つまり、作業内容の記録(コミット)や世界線移動(ブランチ[27]移動)という、作業をする上で多くおこなう事が高速にできる事を意味します。

SVN を他の人と共有する形で使っていた場合、手元にリポジトリがなく、ネットワーク上にのみリポジトリがある状態になります。

そのため、ネットワーク環境が無い状況では、コミットをおこなったり今までの作業内容を見る事ができなくなります。

自分の PC 上にリポジトリを持たないため、その分ハードディスクや SSD の容量が増えるというメリットがありますが、上記のデメリットもあります。

一方 Git では、ネットワーク上の共有リポジトリにコミットしたり、他人の作業内容を受け取る時のみ、ネットワーク接続が必要です。それ以外ではネットワーク接続は必要ありません。

自分の PC 上で作業した内容も、ネットワーク接続をした後にネットワーク上の共有リポジトリに送る事で、他の人(ラボメンなど)に共有されます。

これで、岡部はいついかなる場所でも未来ガジェットのアイデアを書く事ができます。

2.3. 自分の PC 上にあるリポジトリでいろいろ試せる

SVN は基本的に共有リポジトリしかないため、SVN の機能を気軽に試せる環境とは言えないです。

Git は、手軽に自分の PC 上にリポジトリを作れるので、そこで Git の機能を気軽に試す事ができます。

また、共有リポジトリから「クローン[28]」して、自分の PC 上に共有リポジトリのコピーを作って、そのリポジトリでいろいろと試した結果、どうにもならない状態になってしまっても、ふたたび共有リポジトリを手元にクローンすれば何もなかったかのように元通りになります。

そのため、例えばまゆりや、るかが役に立ちたいと思って、岡部や紅莉栖から Git の使い方を教えてもらうとなったときに、岡部や紅莉栖は実際に Git の機能を試しながら教えるという事ができます。

3. 第三章 - 率先躬行のサインポスト

これまで、Git とは何かという事や Git を使う理由について説明してきました。

これらを踏まえ、ここでは実際に Git の様々な操作方法を SourceTree[29]や GitHub for Mac[30][31] というソフトウェアを使用して説明します。

3.1. SourceTree のインストールと設定

SourceTree のダウンロードは以下のURLからおこなえます。SourceTree はWindows と Mac OS X に対応しています。

SourceTree のダウンロードが終わったら、次にインストールと設定をおこないます。Windows と Mac OS X それぞれ説明が分かりやすいページがあるので、そのページを紹介しておきます。

3.2. GitHub for Windows (Mac) のインストールと設定

GitHub for Windows (Mac) のダウンロードは以下の URL からできます。SourceTree とは違い OS ごとに URL が違います。

GitHub for Windows (Mac) のダウンロードが終わったら、次にインストールと設定をします。

GitHub for Mac 限定になってしまいますが、インストール後の設定や使い方について自分が書いた記事があるので紹介します。

3.3. Git によるバージョン管理を始める

任意のディレクトリで Git によるバージョン管理を始められるようにします。例えるならば、未来ガジェット研究所でタイムリープマシンが作られた状態にするものです。

3.3.1. SourceTree でのやり方

SourceTree を起動すると、ブックマークウインドウが表示されます。Windows 版の場合は SourceTree を起動した時に表示される画面の左端に表示されます。Mac 版の場合は 「Cmd + B」というショートカットキーで表示する事ができます。

そのブックマークウインドウの中で、三つ横並びに表示されているボタンのうち、一番左のボタンを押します。

SourceTree のボタン

ボタンを押すといくつか選択肢が表示されますが、その中の「リポジトリを作成」を選択します。すると、リポジトリの保存先ディレクトリや、名前を決める画面が表示されます。

リポジトリ名を決めている状態

情報を入力した上で「作成」ボタンを押すと、空のリポジトリができます。これでタイムリープマシンが作られた状態になります。

ただし、まだ今までの作業内容が無いので、過去に戻ったり改変するという事はできません。

リポジトリが作られた状態

3.3.2. GitHub for Windows (Mac) でのやり方

GitHub for Windows (Mac) を起動すると、左上に「+」ボタンがあります。そのボタンを押して表示された画面の中にある「Create」を押します。

「Create」を押すと「Name」と「Local Path」を入力する欄が表示されます。「Name」にはリポジトリの名前を「Local Path」にはリポジトリを保存しておきたいディレクトリを入力します。

「+」ボタンを押した後「Create」を押している様子

それぞれ入力して「Create Repository」ボタンを押すと、空のリポジトリができます。これでタイムリープマシンが作られた状態になります。しかし、やはり今までの作業内容が無いので、過去に戻ったり改変するという事はできません。

「リポジトリを作った後の画面

3.4. すでにあるリモートリポジトリを使ってバージョン管理を始める

すでにあるリモートリポジトリを自分の PC 上へコピーし Git によるバージョン管理を始められるようにします。

その前に、リモートリポジトリについて少し説明をします。リモートリポジトリとは、自分の PC 以外にあるリポジトリの事を指します。

「自分の PC 以外にあるリポジトリ」ですが「インターネット上や誰かの PC 上にあるリポジトリ」を指します。

他の章で「ネットワーク上のリポジトリ」という言葉がありましたが、これは「リモートリポジトリ」と同じ意味です。

このリモートリポジトリを自分の PC 上にコピーするのがこれから説明する手順です。これにより、例えばラボメンなど、他の人と共同でタイムリープマシンを使って作業ができる体制が整います。

3.4.1. SourceTree でのやり方

では早速、すでにあるリポジトリのを自分の PC 上に作りましょう。再び SourceTree 上でブックマークウインドウを表示します。

そのブックマークウインドウの中で、三つ横並びに表示されているボタンのうち、一番左のボタンを押します。

SourceTree のボタン

ボタンを押すといくつか選択肢が表示されますが、その中の「リポジトリをクローン」を選択します。すると、リポジトリを保存するディレクトリや、名前を決める画面が表示されます。

リポジトリを取得しようとしている状態

「ソースパス / URL」の部分に git@github.com:o2project/steins-gate.git を入力して「クローン」を押すと、GitHub 上にある「steins-gate」というリポジトリが自分の PC 上にコピーされます。

3.4.2. GitHub for Windows (Mac) でのやり方

GitHub for Windows (Mac) を起動すると、左上に「+」ボタンがあるので、それを押して表示された画面の「Clone」というのを押します。

「Clone」を押した後、リポジトリを見つけるための検索窓が表示されます。そこにリポジトリの名前を入力して、目的のものが見つかったら「Clone [リポジトリ名]」というボタンを押します。

クローンする対象のリポジトリを絞り込んでいるところ

「Clone [リポジトリ名]」というボタンを押すと、リポジトリを保存するディレクトリや名前を決める画面が表示されます。

クローンするリポジトリの名前を決めているところ

それぞれ入力して「Enter」を押せば、リモートリポジトリが自分の PC 上にコピーされます。

リポジトリを自分の PC 上にコピーした後

3.5. 作業内容を記録する

作業した内容をリポジトリに記録します。例えるならば、Steins;Gate でストーリーを進めた後、セーブをするようなものです。

3.5.1. SourceTree でのやり方

リポジトリ内にファイルを新しく作成した場合 SourceTree 上ではファイル名の横に「?」が付く形で表示されます。これは、ファイルがまだバージョン管理されてない事を示しています。

変更したファイルにチェックを付ける前

この状態でファイル名の左横にあるチェックボックスにチェックを付けると「ステージングエリア」といわれるところにファイルが移動します。

変更したファイルにチェックを付けた後

移動した状態で、画面の下部にある「コミットメッセージ」と書かれている場所に任意のメッセージを入力します。

コミットメッセージを入力する前

入力した後「コミット」ボタンを押すと、作業した内容がリポジトリに記録されます。なお、初回以降は画面上部にある「コミット」ボタンを押す事により、メッセージを入力できます。

コミットした後

ちなみに、コミットメッセージなどが表示されている場所の「ラベル」部分に「HEAD」という記載がありますが、これは「現時点でどのブランチにいるかを判別する情報」です。つまり、世界線の観測ができているという事で、これを例えるならば、ダイバージェンスメーターです。

3.5.2. GitHub for Windows (Mac) でのやり方

GitHub for Windows (Mac) では、リポジトリ内にファイルを新しく作成した場合、画面上部に「1 Change」と表示され、またファイル名の横にあるチェックボックスにチェックが付いた状態になります。

追加したファイルをコミットする前

GitHub for Windows (Mac) の場合「ステージングエリア」にファイルを移動する必要はなく、そのまま画面下部でコミットメッセージを書く事ができます。

コミットメッセージを入力している最中

コミットメッセージを書いて「Commit to master」というボタンを押すと、作業した内容がリポジトリに記録されます。

コミットした後

3.6. 作業内容を無かった事にする

岡部は、ダルにメールを送信した後、秋葉原 UPX でタイムマシン理論についての講義を受けましたが、ディスカッションで紅莉栖に完全に論破されてしまいました。

岡部にとって、論破されたという事は無くしたい事象ですが Git であればそれができます。

3.6.1. SourceTree でのやり方

方法としては、作業内容を無かった事にするファイルを右クリックで選択し「リセット(Windows の場合は破棄)」を選択します。

作業内容を無かった事にする

変更を本当に破棄していいか確認の画面が表示されるので「OK」を押します。

作業内容を無かった事にするか確認がされる

これで、紅莉栖に論破されたという事が無くなりました。

論破された事を無くした後

3.6.2. GitHub for Windows (Mac) でのやり方

作業内容を無かった事にするファイルを右クリックで選択し「Discard Changes」を選択します。

作業内容を無かった事にする

変更を本当に破棄していいか確認の画面が表示されるので「Discard Changes」を押します。

作業内容を無かった事にするか確認画面が表示される

これで、紅莉栖に論破されたという事が無くなりました。

作業内容が無かった事にされた

3.7. 作業内容の差分を見る

作業内容の差分を見ます。例えるならば、岡部が、まゆりが死んだ理由を前回まゆりが死んだ理由と比較し、そこから試行錯誤するようなものです。

SourceTree と GitHub for Windows (Mac) のどちらでも、特定の作業内容を選択する事で、その作業内容の一つ前の作業内容と比べてどのような変更をしたのか見る事ができます。

SourceTree では、以下のような見た目になります。

SourceTree で作業内容の差分を見ている例

GitHub for Windows (Mac) では、以下のような見た目になります。

GitHub for Windows (Mac) で作業内容の差分を見ている例

3.8. ブランチの一覧を見たり、新たにブランチを作る

ブランチの一覧を見たり、新たにブランチを作ったりします。「ブランチ」は例えるならば「世界線」となり、ブランチを作るという事は「世界線の観測」になります。

また、リポジトリには「HEAD」という「自分が今どのブランチ(世界線)にいるのか分かるファイル」があり、それはダイバージェンスメーターだと言えるでしょう。

では、ブランチを作る方法を説明していきます。なお、現在のブランチは「秋葉原が電気街となり、フェイリスのお父さんが生きている世界線」だとします。

「秋葉原が電気街となり、フェイリスのお父さんが生きている世界線」で鈴羽を引き止めるために、岡部が D メールを送信しました。ここまでの作業内容は以下のようになります。

新たなブランチを作る前

この状態から SourceTree もしくは GitHub for Windows (Mac) を使って「鈴羽を引き止めるために D メールを送信した後の世界線」というブランチを作ります。

3.8.1. SourceTree でのやり方

SourceTree の画面上部にある「ブランチ」を押すとブランチ名を入力する画面が表示されます。この画面内の新規ブランチの項目に任意の名前を入力します。

ブランチ名を決めているところ

「ブランチを作成」を押すとブランチができた状態になり、かつ作ったブランチ(鈴羽を引き止めた世界線)に移動しています。世界線変動が起きました。

ブランチを作った後

3.8.2. GitHub for Windows (Mac) でのやり方

現在のブランチ名が書かれている左横に「線が分岐していて分岐先に "+" が書かれているボタン」があります。

このボタンを押すと「Create New Branch」という画面が表示され、そこには「Name」と「From」の二つの項目があります。「Name」には任意の名前を入力し「From」では分岐元のブランチを選択します。

「Create New Branch」という画面が表示されている状態

それぞれ情報を入力した後「Create Branch」というボタンを押す事により、新しいブランチが作られます。

新規ブランチが作られた図

3.9. 作業内容をリセットする

作業内容を無かった事にします。例えるならば、タイムリープのようなものです。

「作業内容を無かった事にする」と似ていますが、違いとしては「すでにリポジトリに追加した作業内容も無かった事にできる」と「作業内容をリセットしたという事が履歴に残る」があります。

「作業内容を無かった事にする」はリーディング・シュタイナーが働かないので記憶から無くなってしまいますが「作業内容をリセットする」はリーディング・シュタイナーが働くため記憶に残る、と例えると分かりやすいかと思います。

話を戻しますが「鈴羽を引き止めた世界線」でいくつか作業をした結果、履歴が以下のようになりました。最新の作業内容は「SERN の襲撃によりまゆりが死んでしまった…」となっています。

鈴羽を引き止めた世界線でいくつか作業した後の状態

ここで最新の作業内容である「SERN の襲撃によりまゆりが死んでしまった…」という作業を無かった事にして、紅莉栖がタイムリープマシンを完成させたところにタイムリープします。

タイムリープするためには、戻したい作業内容の一つ前の作業内容を右クリックで選択し「このコミットまで "ブランチ名" を元に戻す」を選択します。

git resetをおこなおうとしている状態

これで、作業内容から「SERN の襲撃によりまゆりが死んでしまった…」というのが消えました。

git resetをした後の状態

3.10. 作業内容を改変する

作業内容を改変します。例えるならば、タイムリープマシンを使って過去の作業をやり直す感じです。

電話レンジ(仮)を改造してタイムリープマシンができた後、萌郁やラウンダー達の襲撃もしくは他の要因により、まゆりが何度も死んでしまった状態の最新の作業内容ですが「ラウンダー追ってきて、まゆりが刺されて死んだ」となっています。

まゆりが何度も死んでしまったときの作業内容

3.10.1. コミットメッセージを修正する

まず始めに、コミットメッセージを修正してみます。

先ほどの最新の作業内容を記録したコミットが「ラウンダー追ってきて」と、間に「が」が足りないメッセージになっています。これを修正するため、直したい対象の一つ前の作業内容を右クリックで選択し「"コミット番号" の子を対話形式でリベース」を選びます。

対話形式でリベースを選択している状態

すると、対象となる作業内容が表示されるので、コミットメッセージを直したい作業内容を選び、画面下部の「Edit message」を押します。すると、コミットメッセージを編集する画面が表示されます。

コミットメッセージを編集している状態

任意のコミットメッセージを書いた後「OK」ボタンを押すとコミットメッセージが修正されます。

コミットメッセージを編集し終えた状態

3.10.2. 複数の作業内容を一つにまとめる

次に、まゆりが死んだと書かれた複数の履歴を一つにまとめます。直したい対象の一つ前の作業内容を右クリックで選択し「"コミット番号" の子を対話形式でリベース」を選びます。

git rebase squash するべく親となるコミットを選択している状態

今回は四つの作業内容を対象としました。ここから作業内容をまとめるには「Squash with previous」を三回押します。「まとめる作業内容の数 - 一回 Squash with previous を押す」と覚えるといいかもしれません。

git rebase squash しようとしている状態

その後、まとめた作業内容のコミットメッセージを編集するために「Edit message」を押します。

コミットをまとめた後コミットメッセージを編集している状態

これで、まゆりが死んだと書かれた複数の履歴がまとめられました。

git rebase squashした状態

3.11. ブランチを移動する

現在のブランチから別のブランチへ移動します。例えるならば D メールを送った結果、世界線変動が起こった状態を、任意のタイミングで起こせるというものです。

Git のブランチは「世界線」です。D メールによる世界線変動は、世界の状況に影響を及ぼしてましたが、Git ではそういった副作用が無く世界線の移動ができます。

3.11.1. SourceTree でのやり方

移動の方法は簡単で、画面左端に表示されているブランチ一覧から、移動したいブランチの名前をダブルクリックする事により、ブランチを移動できます。

以下の図では「鈴羽を引き止めた世界線」から「萌郁が IBN 5100 を手に入れた世界線」に移動しています。

ブランチを移動した後

3.11.2. GitHub for Windows (Mac) でのやり方

現在のブランチの名前部分をクリックするとブランチ一覧が表示されます。「Filter」と書かれているところではブランチの絞り込み検索ができます。

ブランチ一覧を表示している図

ここでは「鈴羽を引き止めた世界線」から「萌郁が IBN 5100 を手に入れた世界線」に移動しています。

ブランチを移動した後の図

3.12. リモートリポジトリに作業内容を送る

自分がした作業内容を、リモートリポジトリに送ります。例えるならば、岡部が紅莉栖にまゆりを助けるべくあれこれしてきた事を共有する感じです。

今まで、岡部はまゆりを助けるために何度もタイムリープをおこなって奮闘してきましたが、その事を他のラボメンは知りません。

奮闘している事を知られないままタイムリープマシンを壊そうとしても、紅莉栖に止められるのはしかたないです。

なので、他のラボメン(今回の場合だと紅莉栖)に今まで岡部がしてきた作業内容を伝える必要があります。

画面上部の「プッシュ」を押します。初期設定では現在のブランチのみが選択されているので、その状態で「OK」を押します。

git push 前

プッシュが終わり、作業内容の一覧に「origin/ブランチ名」という文字が表示されるようになりました。なお、「origin」というのは、リモートリポジトリの事を指しています。

作業内容をリモートリポジトリに送ったとともに、紅莉栖にも今までの作業内容が伝わりました。

git push 後

3.13. リモートリポジトリの変更内容を自分の PC 上のリポジトリに取り込む

他人がした変更をリモートリポジトリから取得し、自分の PC 上のリポジトリに取り込みます。

リモートリポジトリでは、岡部以外にもラボメンが作業しています。例えば紅莉栖を見てみると、岡部の様子がおかしいのでタイムリープしてきたのか聞いていたり、マイフォークが欲しいと言った事を記録しています。

その場合、自分の PC 上のリポジトリ(鈴羽を引き止めた世界線)に比べ、リモートリポジトリ(origin/鈴羽を引き止めた世界線)が二つ進んでいます。

紅莉栖が作業している

ここで、画面上部の「プル」を押します。基本は表示された画面内の「OK」を押すだけで良いです。

pull してくるブランチを選んでいる状態

「OK」を押す事により、自分とリモートのリポジトリの作業内容が同期します。

自分の PC 上のリポジトリとリモートリポジトリの同期をとった

3.14. 別のブランチでの作業内容を取り込む

別ブランチの作業内容を現在のブランチに取り込みます。例えるならば、世界線を収束させるための作業です。

「鈴羽を引き止めた世界線」というブランチで作業をした結果、鈴羽がタイムトラベルを失敗して「失敗した失敗した失敗した失敗した失敗した」と何度も書いた手紙を書き残し、自殺してしまいました。

その結果、岡部は天王寺裕吾から鈴羽が書いた手紙を受け取る事になります。

鈴羽を引き止めた世界線でいくつか作業をした例

それを無かった事にするため D メールを送り世界線を変動させて鈴羽を引き止めないようにします。その為には「秋葉原から萌えが消えた世界線」のブランチへ移動します。

秋葉原から萌えが消えた世界線に移動した

移動した後は D メールを送った状態が最新の状態となっています。この状態から「鈴羽を引き止めた世界線」でしてきた作業を「秋葉原から萌えが消えた世界線」に統合します。

方法としては、統合したいブランチの名前を右クリックして「"統合するブランチ名" を "統合させたいブランチ名" へマージ」を選択します。

マージ対象のブランチを選択している状態

選択すると、確認メッセージが表示されるので「確認する」を押します。

マージする際の確認メッセージ

すると「秋葉原から萌えが消えた世界線」に「鈴羽を引き止めた世界線」でしてきた作業内容が統合された状態になります。

マージした後の状態

ただし、まだコミットはされていないのでコミットをしておきます。ここではコミットメッセージを「尾行は中止前のメールは SERN の罠というメールを送信した」としています。

マージした際のコミットメッセージを書いている状態

コミットが完了しました。このように D メールを送信する感覚で、ブランチ同士を統合する事ができます。

マージが完了した状態

3.15. GitHub for Windows (Mac) でリモートリポジトリと同期する

GitHub for Windows (Mac) では画面の右上に「Sync」というボタンがあります。

これは、他の人がした作業内容をリモートリポジトリから取得して自分の PC 上のリポジトリに取り込みつつ、自分の PC 上のリポジトリに作業内容がある場合はそれをリモートリポジトリに送信します。

つまり「git push」と「git pull」を同時におこなうものと考えれば良いでしょう。

Sync を押す前

「Sync」を押すと、同期の進捗を表すバーが表示されます。

Sync を押して同期をしている

あとがき

GitHub と Bitbucket について

「リモートリポジトリ」というキーワードが書籍中に何度か出てきました。

このリモートリポジトリですが、例えばラボメンと共同で何か作業する(タイムリープマシンを作るなど)ときは必須になってきます。ですが、サーバーを用意して Git を設定してという手順をするのは面倒です。

なので、Git の仕組みを使って、自分達が作ったプログラムコードなどを共有できるサービスがいくつか出てきました。

その中の一つがこれから紹介する GitHub[32] と Bitbucket[33] になります。 

ちなみに、この書籍も GitHub で管理されています。[34]

GitHub と Bitbucket 共通の機能

GitHub と Bitbucket どちらにも Issues・Fork・Pull Requests という機能があります。それらについて説明します。

Issues

バグやマイルストーン(目標)などを管理するものです。バグトラッキングシステムともいいます。例えるならば、鈴羽がタイムマシンが壊れているのに気づき、その事を Issues に追加し、ダルが対応するという感じです。

例えば、リポジトリにあるコードが何か予期しない動きをしたときなどにバグ報告をしたり、新しい機能を追加するときにマイルストーンで管理をする事ができます。

Fork

GitHub や Bitbucket 上で公開されているリポジトリを、自分のリポジトリとしてコピーする機能です。全ての公開されているリポジトリは Fork をする事ができます。

リポジトリに対して何か変更を加える場合、例えば機能を追加したい、説明書に誤字を見つけたので修正したい、といったときに Fork をして自分の手元で変更を加えます。

Pull Requests

Fork した後にリポジトリに対して変更を加えたところを、Fork 元のリポジトリに取り込んでもらうように希望する機能です。

Git は自分が管理していないリポジトリに何か変更を加えたい場合、変更できる権利が必要になってきます。しかし、やたらと変更できる権利を与えてしまうと、変な変更が加えられてしまう可能性があります。

Pull Requests は、元のリポジトリを変更する権利を与えないかわりに、Fork 元のリポジトリに自分が変更を加えたものを取り込んでもらうように希望する機能です。

この機能があるので、変更を取り込む作業を Fork 元のリポジトリを変更できる権利を持っている人達に委ねる事ができます。

利点としては、Fork 元のリポジトリの管理者は変更できる権利を与えなくて済むのと Fork 先のリポジトリで変更した点を取り込む前に確認できるので、リポジトリに変な変更が加えられてしまうのを防げるという点にあります。

参考にした資料

本書を書くにあたり参考にした資料の一覧となります。本書を読み、より Git について知りたいと感じたときには、以下のサイトや書籍を見てみるといいでしょう。

Webサイト

  • Gitチュートリアルとトレーニング| Atlassian[35]

  • イラストでわかる!git入門の入門 : アシアルブログ[36]

  • Git - Book[37]

  • 初心者でも分かる!git rebaseの使い方を解説します | 株式会社LIG[38]

書籍

  • シュタインズ・ゲート公式資料集[39]

  • 入門git[40]

  • 開発効率をUPする Git逆引き入門[41]

  • GitHub実践入門 Pull Requestによる開発の変革[42]

作者

  • 執筆: kubosho_[43]

  • アシスタント: fruitsnoodle[44]

  • 表紙・各章のイラスト: GiantRobot[45]

  • 発行所: 日光企画[46]

Git のロゴについて

  • Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.


1. https://twitter.com/kyo_ago/
2. ちなみに「Steins;Git」という言葉をたどると、@ruedap が2011年6月29日にしたツイートが最初かと思われます https://twitter.com/ruedap/status/82250750268420096
3. https://twitter.com/kyo_ago/status/413586733008044032
4. https://twitter.com/watilde
5. https://gitter.im/o2project/steins-git
6. https://github.com/yosiwo
7. https://twitter.com/GeckoTang
8. http://blog.o2p.jp/2014/07/23/c86-steins-git.html
9. https://github.com/fruitsnoodle
10. pixivID:1223059
11. http://dictionary.reference.com/browse/git
12. http://ja.wikipedia.org/wiki/Git#.E5.90.8D.E5.89.8D.E3.81.AE.E7.94.B1.E6.9D.A5
13. https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27Git.27_name.3F
14. ソースコードなどを任意のタイミングで抜き出したもの。詳しくは http://e-words.jp/w/E382B9E3838AE38383E38397E382B7E383A7E38383E38388.html を参照してください。
15. 第三章の「作業内容を記録する」で解説しています。
16. 第三章の「リモートリポジトリに作業内容を送る」で解説しています。
17. 第三章の「作業内容を無かった事にする」で解説しています。
18. リバートについてはこの記事が詳しいです。「Gitを使いこなそう!知っておくと便利な使い方 ~Tower2・SourceTree~ – ICS LAB http://ics-web.jp/lab/archives/3184
19. 第三章の「リモートリポジトリの変更内容を自分の PC 上のリポジトリに取り込む」で解説しています。
20. http://www.google.com/trends/explore#q=Git%2C%20SVN%2C%20Subversion&geo=JP&date=4%2F2005%20112m
21. http://qiita.com/
22. http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=svn
23. http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=subversion
24. http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=git
25. http://stackoverflow.com/
26. http://stackoverflow.com/tags
27. 第三章の「ブランチの一覧を見たり、ブランチを作ったりする」で解説しています。
28. 第三章の「すでにあるリモートリポジトリを使ってバージョン管理を始める」で解説しています。
29. https://www.atlassian.com/ja/software/sourcetree/overview
30. https://mac.github.com/
31. Windows 版は https://windows.github.com/
32. https://github.com/
33. https://www.atlassian.com/ja/software/bitbucket/overview
34. https://github.com/o2project/steins-git
35. https://www.atlassian.com/ja/git/tutorial
36. http://blog.asial.co.jp/894
37. http://git-scm.com/book/ja/
38. http://liginc.co.jp/web/tool/79390
39. http://www.amazon.co.jp/dp/4047263745
40. http://www.amazon.co.jp/dp/427406767X
41. http://www.amazon.co.jp/dp/4863541465
42. http://www.amazon.co.jp/dp/477416366X
43. https://github.com/kubosho
44. https://github.com/fruitsnoodle
45. pixivID: 1223059
46. http://www.nikko-pc.com/