チーム開発勉強会が開催されました(2)

去る6月27日(土)、ゆうMUGの本拠地・永山公民館にて「チーム開発勉強会」が開催されました。参加者こそ5名と少なかったものの、非常に熱のこもった質疑が展開されました。今回はその後半の模様をご紹介します。

GitHubとは

IT分野では既に説明する必要がないほど有名になったウェブサービスですが、一般の方にはまだまだ馴染みが浅いかもしれません。一言でいうと、前回紹介したGitを使いこなすためのハブとしてユーザーを繋ぐためのサービスです。

一番重要な機能は、Gitのリポジトリを提供してくれること。クラウド上のサービスということもあって共有や共同作業の支援に力をいれているだけでなく、自分だけ使えるようにするためにお金を払う、という独特の料金体系になっています。ゆうMUGではこの「自分だけで使える」プライベートリポジトリを5つまで利用できるアカウントを持っていて、各ゆうMUGアプリのソースコード管理に利用しています。

GitHub
GitHubを始めるにはこんな感じで

また、複数のリポジトリを連携する機能として「Fork」と言われるメカニズムを持っています。これは、大元になるリポジトリを単にコピーするだけでなく、何がどのようにコピーされたかを管理する仕組みを提供してくれています。例えば、ゆうMUGのプライベートなリポジトリにアクセスするには共同開発者(コラボレーター)としての登録が必要なのですが、各コラボレーターがForkして新たに作成されたコピーにもこの制限がそのまま適用されます。ですから、秘密のプロジェクトを秘密のまま、関係者の間だけでコピーしたりすることが可能になるわけです。

Git Flow

Git、およびGitHubはとても強力なツールなのですが、あまりに自由度が高すぎるので、ある程度は別枠でローカルルール的なものを定めた方がよろしいとされています。あちこちでこのルールが提唱されており、それぞれ一長一短あるようなのですが、勉強会ではそのひとつとして「 Git Flow」について勉強しました。

Git Flowは A successful Git branching model で提唱されているもので、一見するとかなり複雑な構造をもっています。下図は上記サイトから全体像をお借りしたものです。

Git Flow
Git Flowは一見かなり複雑です

勉強会では、この複雑な全体像をいくつかに分解し、それぞれの操作と意味を学びました。Git Flowで定義されているブランチ名は下記の通り5つあるのですが、それぞれの定義と連携方法を整理することでずいぶんわかりやすくなりそうです。

  • master
  • develop
  • release
  • hotfix
  • feature

ふたたびSource Tree

さて、いくら複雑な構造を整理し、理解したとしても作業の複雑さは変わりません。Git Flowを手作業で運用するのは至難の業だと思われますが、前回も紹介したSource Treeは大変強力なGit Flow支援のしくみを持っています。

Source TreeのGit Flow支援
Source Treeはとても強力なGit Flow支援のしくみをもっています

メニューバーから「リポジトリ」→「Git flow / Hg flow」を選択すると上のような表示になります。ここからフィーチャー、リリース、ホットフィックスの各ブランチを自動的に正しく生成することができ、作業終了後はそれぞれを終了して元のブランチに統合する作業を行ってくれます。

ふたたびGitHub

勉強会最後のネタはふたたびGitHubに戻って「プルリクエスト」の勉強です。いったんForkして手元に複製されたリポジトリでは作業者が自由に開発を進めることができますが、開発がうまくいってひとつの機能が完成したら、大元のリポジトリに反映する作業が必要です。

そこでPull Request

Gitではこの「手元の変更を大元に反映する方法」がいくつもあるのですが、やはりそれぞれに一長一短があります。GitHubでは「Pull Request」という手法を推奨しており、それを支援する機能が作り込まれています。

Pull Request
こんな感じでソースコードを比較します

具体的には、複数のソースコードを比較した差分を作成し、それを大元の管理者に対し「こんな変更をしてみたんだけど、よかったら反映してくれませんか」というお願いをすることになります。管理者がこれを反映するかどうかを決める前に関係者間で議論する仕組みも備わっていて、誤った変更が不用意に反映されてしまうことを防ぐようになっています。また、なぜそのような変更をしたのか、それがなぜうまく動作するのか、といったノウハウ的なことも継続的に蓄積することができるため、最近では個人/団体/企業を問わず広く使われるようになってきているようです。

参加者の声

以上、少人数でしたがとても盛り上がった勉強会になりました。予定時間を大きくオーバーしてしまったため、質疑応答や自由討論の時間があまり取れなかったのが残念でした。

また参加した皆さんからはこんな声が挙がっていました。

  • GitHubはネット上で誰かが書いたコードを共有するシステムだと分かっていましたがVersion管理システムになっていたとは知りませんでした。個人で勉強するには限界があるので実際に画面を見ながらの勉強会は本当にありがたいです。
  • 勉強会は出来れば和室ではなく、椅子にすわってやりたいです。
  • 以前、勤めていたところでは下の version管理コマンドに sccs を使ってその上に Git Hub によく似たシステムを作って製品の開発・管理をしていました。使われている単語は違いました。例えば push は、putback, clone は bringover, repository は、workspaceなどです。pull request もあって、これは rti (request for integration) でした。rti を出すためには踏むべきステップ(決められたテストの実行、マージ・コンフリクトの解消、コーデイング基準に順守していること、その他)があってそれらが満たされていなければ rti は即座にリジェクトされました。Git Hub も個人で使う場合、少人数のよくお互いをしったグループで使う場合、会社で製品開発をする場合、不特定多数が関わるオープン・ソースのシステムを開発する場合など、使われ方はいろいろだろうなと思いました。
  • Git を全く知らなかったので、驚きでした。で、面白かったです。
  • 告知と同時に予習すべきソフトがわかっていると、少し余裕をもって予習できたかなと思います。
  • 後でしまったな〜と思ったのが、Git の操作を自分の端末でも一緒にやれれば良かったなと思いました。サルでもわかるGit入門」でcommitteeしたファイルを一つ作っていたので、惜しいことをしたと思いました。
  • 今回の勉強会のテーマは「チーム開発」なので GitHub が重要でしたがチーム開発でなくて個人で管理するいろんなファイル、例えば日記とか、ノートとか、を履歴を取りながら管理したいときは GitHub までいかなくても、git だけ自分のローカルマシンで使って管理するのも便利です。

またお会いしましょう

ゆうMUGでは、今後もいろいろな活動を展開していきます。公式ウェブサイト(ここです)で告知していきますので、ぜひお見逃しなく。


 関連記事

参考リンク