agileツール適合化分科会（gitとgit hub）

1Copyright (C) Masanori Kataoka. All Rights Reserved.

ソフトウェア変更管理・バージョン管理技術

～ GitとGitHub～

２０１５年８月２５日

片岡雅憲

2015/8/261

Agileツール適合化分科会（第６回）資料


＜内容＞

１．変更歴管理、そしてバージョン管理２．変更歴管理・バージョン管理システムの歴史３．Git

４．GitHub

５．GitHubとCIツールの連携６．まとめ＜付録＞Gitの代表的なコマンド＜参考文献＞


1.1 変更歴管理の重要性ソフトウェアは、その開発の過程においても、また、運用・保守の段階に入っても、頻繁に変更される。この変更を記録し、また、過去を復元するために変更歴管理は重要である。

１）失敗に気付いた場合に（不良を検出した場合を含む）、失敗を検討・修正するための過去の状態に戻りたい。いわば、タイムマシンにより、過去のいかなる時点にも戻りたい。２）同一のコードに対して、複数の開発者が、管理された方法で並行アクセスし、チームによる共同開発を行ないたい。３）既にリリースされたコードを保守しながら、最新のコードの開発を並行して進めたい。４）変更の経時的な記録を残したい。変更の理由、回数等の情報を後で利用したい。


1.2 変更歴管理からバージョン管理へソースコード変更歴管理技術は、より論理的な単位を扱うバージョン管理技術へと発展していった。１）ソースコードを個人の所有物としてではなく、開発チームメンバー全員による共有リソースとして扱う。

２）単に断片的なソースコードの変更差分を扱うのではなくて、タグによりグループ化する。また、ソースコードの論理的時系列集合であるコードラインを管理するようにする。

３）コードラインおけるメインライン（トランク）とブランチとを設けて、並行作業が出来るようにする。これにより、空間的、時間的に分散したチーム間の協業を可能とする。

４）ソフトウェアのリリースにあたり、ブランチを使ってリリースし、メインラインは開発を継続できるようにする。

５）ブランチの変更は、テスト完了後に、メインラインの変更へマージする。


1.3 バージョン管理上の留意事項１）出来るだけ頻繁にチェックイン（正式な変更処理、Commit)する（１～数回/日）。これにより、失敗した時に着実に回復出来る。２）基本的にメインラインにチェックインする。ブランチにチェックインした場合は後で、再度メインラインにチェックイン（マージ）することになる。３）チェックインのメタデータ（変更理由の説明等）を、分かり易く記述する。不良修正においても、これがなおざりにしてはならない。４）あらゆるリソース、およびそれに関する情報をバージョン管理下におき、旧バージョンが環境も含めて確実に再現出来るようにする。５）リリースをする場合に、ブランチを作成して、そのブランチ上でリリースする。リリースしたものの不良はブランチ上で修正する。そしてまた、メインライン上にも修正をフィードバックする。６）広く利用されているソフトウェアほど、個別顧客対応、不良対応の多様なバージョンを提供している場合が多い。このようなソフトウェアにおいてはバージョン管理は極めて重要な仕事になっている。


1.3 バージョン管理上の留意事項（続き）７）大規模な機能の追加や変更を行う場合に、ともすると、メインラインに迷惑をかけたくないとの理由でブランチを作りたくなる。しかし、現実にはブランチを作ることは容易でも、これをメインラインにマージするのには大変な苦労が伴う。大規模な追加、変更であってもメインライン上でコツコツと着実に進めた方が結局は早道である。８）ブランチ上でリファクタリングを行った場合には、このブランチをメインラインにマージするのに苦労することが多いので注意が必要である。

（注）上記の７）、８）は、Subversionまでの変更歴管理・バージョン管理システムにおいては重要な留意事項であった。しかし、Git,

GitHubにおいては、ブランチを広い範囲で積極的に活用していこうとの考え方が主流になっており、７）、８）はバージョン管理上の留意事項にはなっていない。


変更歴管理・バージョン管理システム発展の歴史を、次に概説する。１） SCCS(Source Code Control System)：１９７２年にIBM System/３７０上にベル研Marc J.Rochkindが開発、その後、ＵＮＩＸ上に移植される。バージョン管理システムの元祖とも言うべきツール。

２） RCS(Revision Control System):

パデュー大学でWalter F. Tichyが１９８０年代に開発、その後、GNUソフトに組み入れられ、現在も使われている。複数ユーザは扱えない。

３） CVS(Concurrent Version System):

RCSをベースに、①クライアントサーバ機能 ②ブランチ、タグ機能等を強化した。ネットワーク上で複数ユーザを扱うことが出来る。Dick Gruneが開発し、１９８６年にオープン化、１９８８年にB. BerlinerがC環境に移植した。関連する複数のファイルに対する操作をアトミックに（一つの操作として）行うことは出来ない。


４） Subversion:

CVSの問題点を解決するものとして、K. Fogel, Ben Collins-

Sussman他により開発され、２００１年に公開された。彼らは、CVS

に精通しており、コマンドはCVSに合わせてあることから、CVSを置き換えて急速に普及した。

RCS, CVSでは、管理の基本単位がファイルになっていて、これが処理時間の長さや、排他制御機能の限界の要因になっている。Subversionは、管理単位をリビジョン（変更差分）としており、このような課題を克服している。また、関連する複数のファイルに対する操作をアトミックに（一つの操作として）行うことが出来る。

Subversionは、集中管理方式の開発では、優れたものになっていて、現在最も多く使われている。しかし、分散型開発のバージョン管理には対応していない。これには、Git等の分散型バージョン管理システムが必要である（Gitについては後述）。


５） Git:

Linuxカーネルの開発においては、分散バージョン管理ツールである BitKeeper が使われていた。BitKeeperは、商用ツールであったが、無料版も配布していて、これを使っていた。しかし、２００５年春に無料版の条件を厳しくしたために、Linuxでは継続使用が不可能になった。

BitKeeperの代替品を探したが適切なものがなく、LinuxプロジェクトのリーダーであるLinus Torvaldsと同僚の濱野純の２人が中心となって、Gitの開発を始めた。開発開始後、３か月経った２００５年７月には、当初バージョンが開発、公開され、その後、オープンソフトウェアコミュニティの中で急速、かつ着実に改良が加えられ、ユーザ数を増やしていった。

Gitによる分散開発は、①地理的に分散した開発 ②異なるメンバー、チームによる並行開発の二つの意味が込められており、その両者ともを支援する機能を備えている。


３．Git

3.1 Gitの概要Gitは、Linuxのソースコード管理を目的として、Linuxの開発リーダであるLinus Torvaldsとその同僚である濱野純により開発された。分散型バージョン管理システムであるのが特徴である。分散環境での変更管理はローカルなリポジトリを使って行われる（リモートのセントラルリポジトリにアクセスしないで行われる）。データの圧縮に工夫をしていて、Subversionに比較して動作性能が格段に優れている。また、ブランチを用いた同時並行開発が容易に行えるようになっている。ブランチの作成、そしてブランチのメインラインへのマージが容易に行える。ブランチはバグ修正から新機能開発まで幅広く活用できる。


３．Git

3.2 Gitの特徴Gitは、その開発の経緯からして次のような特徴を持っている。１）分散開発を容易にする。セントラルリポジトリと同期をしていなくても、分散リポジトリで独立して、並行開発が出来る。分散リポジトリは、セントラルリポジトリの全コピーを保持している。２）何千人もの開発者を扱える。３）高速である。データ容量を節約して、転送時間を短縮するための、データ圧縮技術、差分管理技術が優れている。C言語で記述されている。（図3.1と表3.1にGitとSubversionの性能比較を示す。）４）SHA1という暗号学的ハッシュ関数を用いて、全てのオブジェクトの

IDをユニーク化して、完全性や信頼性を維持している。５）ブランチを作成して（分岐して）、分散開発した後の、マージ処理を容易に行うための機能を備えている。ブランチ作成、マージの操作が容易であり、かつ高性能である。ブランチを小さなバグ修正から、大きな機能追加開発まで、広範囲に適用できる。


３．Git

3.2 Gitの特徴（続き）

図3.1 GitとSubversionの性能比較（参考文献１３）より転載）


３．Git


Operation Feature Git SVN ratio

Commit Files(A)

Add, commit and push 113 modified files (2164+, 2259-)

0.64 2.60 4x

CommitImages(B)

Add, commit and push 1000 1k images 1.53 24.7 16x

Diff Current Diff 187 changed files (1664+, 4859-) against last commit

0.25 1.09 4x

Diff Recent Diff against 4 commits back (269 changed/3609+,6898-)

0.25 3.99 16x

Diff Tags Diff two tags against each other (v1.9.1.0/v1.9.3.0 )

1.17 83.57 71x

Log(50) Log of the last 50 commits (19k of output)

0.01 0.38 31x

表3.1（１） GitとSubversionの性能比較（参考文献１３）より転載）（数値の単位は秒）


３．Git


Operation Feature Git SVN ratio

Log(All) Log of all commits (26,056 commits - 9.4M of output)

0.52 169.20 325x

Log(File) Log of the history of a single file (array.c - 483 revs)

0.60 82.84 138x

Update Pull of Commit A scenario (113 files changed, 2164+, 2259-)

0.90 2.82 3x

Blame Line annotation of a single file (array.c) 1.91 3.04 1x

Clone Clone and shallow clone(*) in Git vs checkout in SVN

107.521.0(*)

14.0 0.1x1x(*)

Size(M) Size of total client side data and files after clone/checkout (in M)

181.0 132.0 0.7x

表3.1（2） GitとSubversionの性能比較（続き）（参考文献１３）より転載）（数値の単位は秒）


３．Git

3.3 分散バージョン管理の仕組み1）分散リポジトリ

Subversion等の従来型のバージョン管理システムでは、集中型リポジトリにより、すべてのデータをセンタに集中管理して、これをネットワーク等を経由して共有させる。

Gitでは、ユーザ各人が専用のローカルリポジトリを持つ。ローカルリポジトリには、セントラルリポジトリのすべてのコピーを持つ。ユーザは、センターとのネットワーク接続が切断された状態であっても、ローカルな作業は継続できる。そして、必要な時にセントラルリポジトリと同期を取る。２）何を格納するか

Gitでは、ソースコードだけでなく、そのプロジェクトで必要とされるあらゆるリソースを格納し、バージョン管理する。リソースの本体データは、バイナリ―形式で格納される。


３．Git

3.3 分散バージョン管理の仕組み（続き）３）ワークツリー(Work Tree)とインデックス（Index)

Gitでは、リポジトリがセンターにあるのではなく、各ユーザーのローカルマシン上に作られる。実際に変更を行うには、このローカルなリポジトリから”checkout”することにより、作業用のコピーを作成する。この作業コピーをワークツリー（Work Tree）と呼ぶ。変更・追加の作業はこのワークツリーの上で行われる。

Gitでは、ディレクトリとワークツリーとの間にもう一つのレイヤーでであるインデックス(Index)が存在する。ワークツリー上の変更・追加は、”add”コマンドによりインデックスに反映される。これを「ステージされた変更」と呼ぶ。このステージされた変更を重ね、妥当性を検証した後に、正式な変更として、ログメッセージを付けて“commit” する。これにより変更はディレクトリに反映される。このように、Gitでの変更は2段階に分けられている。 “commit”することにより、新しいリビジョンが作られ、これがログメッセージと共に保存される。


３．Git

3.3 分散バージョン管理の仕組み（続き）３）ワークツリー(Work Tree)とインデックス（Index) （続き）ワークツリー上の変更には多様な作業が混在しうる。例えば、新しい機能を開発中に、ベースとするソースコードの中に不良を発見してその修正も行ったとする。この新機能の開発のための変更と不良修正のための変更を一つの同じ”commit”

で更新することは混乱を招く。インデックスを介して、この二つの変更を切り分けて別の”commit”とする必要がある。ワークツリー上の変更のすべてをひとまとめのものとして”commit”する場合には、”commit –all”により、インデックスを経由なしで出来る。

ローカルディレクトリ

ワークツリー

インデックス

“add”

“commit”

“commit

--all”

図3.2 インデックスによるステージング


３．Git

3.3 分散バージョン管理の仕組み（続き）

４）上位リポジトリとの同期分散管理をしているために、必要に応じて上位の中央リポジトリに自分の変更を反映する必要があり、これは”push”により行われる。また、逆に上位のリポジトリの変更を取り込む必要があり、これは、”fetch”で行われ、取り込んだ変更と自分の変更とを”merge”する。”pull”により、”fetch”と”merge”を同時に行うことが出来る。５）タグとブランチプロジェクトがあるマイルストーンに達した時に、その時のリポジトリの状態に対して分かりやすいタグをつけられる。また、分岐をした時はそれにブランチ名を付けられる。

（注）タグとブランチの詳細については、3.5、3.6節で後述。


３．Git

セントラルリポジトリ―

ローカルリポジトリ―

ワークツリー（作業コピー）

checkout commit

pull/

fetchpush

3.3 分散バージョン管理の仕組み（続き）４）上位リポジトリとの同期分散管理をしているために、必要に応じて上位のセントラルリポジトリに自分の変更を反映する必要があり、これは”push”により行われ

また、逆に上位のリポジトリの変更を取り込む必要があり、これは、”fetch”で行われ、取り込んだ変更と自分の変更とを”merge”

する。”pull”により、”fetch”と”merge”を同時に行うことが出来る。

図3.3 ローカルリポジトリ―とセントラルリポジトリ―の同期


３．Git

3.3 分散バージョン管理の仕組み（続き）

５）タグとブランチプロジェクトがあるマイルストーンに達した時に、その時のリポジトリの状態に対して分かりやすいタグをつけられる。また、分岐をした時はそれにブランチ名を付けられる。

（注）タグとブランチの詳細については、3.5、3.6節で後述。


3.4 Gitの内部構造１）Gitのオブジェクト：図3.4に示すように次の4種類から構成される。

a)ブロブ(blob): binary large objectを意味し、データ実体が含まれていて、メタデータ（名前も）は含まれていない。

b)ツリー(tree): 1階層分のディレクトリ情報を持つ。その配下の全ファイルのブロブID、パス名、また、再帰的に参照する他のツリー名を含んでいる。Commitにより新しいツリーが作られ、変更されたファイルに対してだけ新しくblobが作られる。変更されていないファイルに対するblobは変更されない。ツリーはこの両方のblob

をポイントする。c)コミット(commit): リポジトリに加えられた各変更のメタデータを保持する。具体的には、作者、コミッター、コミット日付、ログメッセージ、コミットが実行された時のツリーオブジェクトを記録している。

d)タグ(tag)、ブランチ(branch):特定のコミットオブジェクトに対して、人が読める分かりやすい名前を付けるための情報を含む。

３．Git


３．Git

3.4 Gitの内部構造（続き）２) Gitオブジェクトの相互関係

作成者Jon Lツリー

8675309

ブロブdead23、ブロブfeeble

V1.0 master

タグ2504624

コミット1492

ブランチ名

ブロブdead23

ブロブfeeble

ツリー8675309

図3.4 Gitオブジェクトの相互関係（参考資料５））


３．Git

3.5 ブランチユーザーが単独で開発を進めているときでも、開発の途中で過去の不良を見つけたときに、この不良対策と追加機能の開発とを並行して進める必要性がある。また、複数のメンバーで開発している場合には当然のこととして並行開発が行われる。ブランチ（branch)はこのような並行開発を可能にする手段である。ブランチを作成・保守する作業は、subversion以前の変更歴管理・バージョン管理システムにおいては極めて重い、手間のかかる作業であった。Gitでは、ブランチの作成を極めて容易に、軽快に（高速に）行えるようになっている。また、ブランチに関連する作業に関して極めて豊富な機能が用意されている。すなわち、Gitは次のような開発を支援する優れたツールになっている。① 高頻度な変更作業とその管理（アジャイル開発）② チームによる共同開発作業（チーム開発、ソーシャルコーディン

グ）


３．Git

3.6 タグブランチは、更なる開発のための「枝分かれ」であり、先へ先へと進んでいく。一方、タグ(tag)は、変更履歴の中で重要なcommit にブックマークを付けておきたいときに使われる。すなわち、commitに対する分かり易い名前を付けることになる。

Git のタグには、軽量タグ(lightweight tag)と、注釈つきタグ（annotated tag)の２種類がある。前者は単にcommit に対するポインタとして扱われる。後者では、メッセージを書いて付加することが出来て、タグの意味付けを明確にする。注釈つきタグには、GPG(GNU Privacy Guard)で電子署名をすることが出来る。この電子署名により、そのタグが示すcommit までのすべての開発作業に対し、開発内容に責任を持つことと著作権を宣言することになる。


３．Git

3.6 GitとSubversionの連携現状において、Gitには勢いがあり、急速にユーザ数を伸ばしている。元々、Gitは、分散開発を目的として開発されたものでありSubversion

の後継として開発されたものではないが、今や、Subversionの競合ツールとみなされている。とはいうものの、いまだ、Subversionのユーザ数は圧倒的な多数を占めている。SubversionとGitの共存のための相互関係として、次が可能であり、そのためのツールが用意されている。１）Subversionのデータを全てGitに変換する。２）Subversionのデータをそのまま活用し、そこから必要とされる変更差分だけをGitに取り込む。また、逆に、Gitでの変更差分をSubversionに戻す。


４．GitHub

4.1 GitHubサービスGitHubは、Gitを利用するプロジェクトのためのホスティングサービスである。また、GitHubは、Gitとその他のツールが連携するための機能（Hubとしての機能）も提供している。GitHubは、現在GitHub社が運営しており、2008年からサービスが開始されている。

GitHubを利用すれば、設備の準備に気を使うことなく、グローバルな分散開発が出来る。このために、Eclipse等の多くのOSSプロジェクトがGitHubに移行していて、現状ではOSSプロジェクトの半数を超えているという。OSSプロジェクトは、GitHubを無料で利用出来る。主要なOSSプロジェクトがGitHubに移行していること、また、GitHub

専用の最新ツールが拡充されてきていることから、GitHubは新しい世界標準としての地位を獲得しつつある。

Gitは、コマンドベースのツールであるが、GitHubでは、Gitインタフェースを内部に隠ぺいし、全てをWebインタフェースで利用できるようにしている。


図4.1 OctCat（GitHubのSymbol）

４．GitHub


４．GitHub

4.2 GitHubの主要機能GitHubが提供している主な機能は次の通りである。

１）OrganizationアカウントGitHubをグループで利用することが出来る。ソースコード情報だけでなくイベント情報や管理情報もグループで共有できる。２）Issue管理機能バグや改善要求などの課題とその処理状況をIssueとして管理する。

Redmine, TracなどのIssue管理専用ツールに負けない機能を持つ。これらのIssue管理専用ツールよりも軽量で使い易いという人もいる。３）Pull Request機能機能追加やバグ修正などの結果をGitHubリポジトリに登録（push)

したものを、他の開発者が取り込む（pull)ための要求を発行する。この機能によりGitHubでは、チームによる開発、いわゆる「ソーシャルコーディング」が可能となる。


４．GitHub

4.2 GitHubの主要機能（続き）４）hubコマンド

Gitコマンドをラップしてさらに高度の機能を付け加えて使い易くしたCLI(Command Line Interface)機能である。Git + hub = GitHub との説明がされているように、GitHubの代表的な機能である。GitHub

では初心者はGUIを、上級者はCLIを利用するものと想定している。５）Git Flow機能リリースを中心に据えたバージョン管理を支援する（図5.2参照）。図4.2における各ブランチは次の役割を分担している。①master:常に正常に動作する状態のブランチ②develop：開発の中心となるブランチ。開発者がこれを直接に更新することはなく、featureブランチからマージする。③feature: developを起点としてfeatureで開発作業を行う。④release: リリース用のテストとバグ修正を行い、masterにマージ⑤hotfixes: 運用中に検出されたバグの修正、確認を行う


図4.2 A successful Git branching model （参考文献8)を参照）

４．GitHub


４．GitHub

4.3 Pull Request 機能Pull Request 機能は、GitHubの代表的な機能の一つであり、いわゆるチームコーディング、ソーシャルコーディングを可能とする。すなわち、プログラマーが一人でコーディングの完成を判断するのではなく、チームで、あるいはプログラマーコミュニティーの助けを借りて、コーディングを完成していく。プログラマーは、自分で作り上げたソフトウェアの変更分をPull

Request の形で、チームの仲間、あるいは特定のパートナーに送る。送られた方は、これをコードレビューあるいはテストの形で検証し、問題があればPull Request のコメントの形で送り返す。そして、これらのコメントを吸収して、確認テスト完了したうえで、master file に反映する。この一連の作業フローをネット上でリアルタイムで実現するための機能をGitHubは提供する。

Pull Request 機能は、上記のようなチームコーディング、ソーシャルコーディングを効率よく実現し、ソフトウェアの信頼性を改善する。


４．GitHub

4.3 Pull Request 機能（続き）Pull Request 機能は、次の二つの機能と連携する。① Issue管理機能② Chat機能

Pull Request機能は、Issue管理機能と連携する。GitHubは、Pull

Requestが発行されると同時にこれに対応したIssueを発行して、このPull Requestがどのように処理されているかをフォローしていく。また、チャット機能とも連動する。例えば、Gitterというチャット機能を

Issue管理機能と一緒に用いることにより、関係者がリアルタイムで連携しながらIssue(Pull Request)の処理を加速化することが出来る。


４．GitHub

4.4 SourceTree

SourceTreeは、当初はMac OS X用に開発されていた無料のGit／Mercurialのクライアントアプリケーションで、GUIによる直観的なバージョン管理の操作が可能なことを最大の特徴としている。2011年にAtlassian社に買収され、Windows用の正式版が2013年6月に公開された比較的新しいツールである。

SourceTreeの使い易さは最近になって急速に着目されている。Git

管理ツールとして有名なTortoiseGitとEclipseのGitプラグインであるEGitと、SourceTreeとを、Google Trends上で普及率を比較したものを図4.3に示す。SourceTreeが急速に普及しつつあるのが分かる。

SourceTreeの具体的な使い易さを上げると次のようになる。１）グラフィカルなコミット履歴の表示グラフによりcommit履歴を表示できる。いつ、何がコミットされたか、ブランチがどのように出来て、それがどうマージされたかを簡単に確認出来る。


４．GitHub

4.4 SourceTree（続き）

図4.3 Google ＴｒｅｎｄｓによるＧｉｔ用バージョン管理ツールの普及率の比較（参考文献10））


４．GitHub

4.4 SourceTree（続き）２）直観的なコミット単位の選択

Gitでは、図3.2に示すようにワークツリーとディレクトリの間にインデックスが介在し、ステージングが行われる。ソースコードのどの部分がこのうちのどこに存在するのかの管理が煩わしい。SourceTree

では、①Working Copy Changes ②Staged Changes

③Uncommitted changes ボタンを押下すればこれらを明示してくれる。３）簡単なMerge操作前記１）のcommit履歴グラフ上でmerge対象範囲をグラフィカルに指定できる。４）直観的なrebase

ブランチの分岐元を付け替えるrebaseは、分かりづらい操作である。SourceTreeでは、と同様にcommitグラフからrebaseするブランチのcommitを選択するだけで、commitの分岐元を付け替えられる。


４．GitHub

4.4 SourceTree（続き）５） CherryPick操作が容易他のブランチのcommitをカレントブランチへmergeするCherryPick

操作もcommit履歴グラフ上で簡単に指定できる。６）セントラルリポジトリとの同期

SourceTreeは、リモートブランチの自動フェッチ機能を持っており、セントラルリポジトリの変更があった場合に、これをローカルリポジトリ上で作業中に簡単に把握出来る。７） Git Flow機能のサポート

SourceTreeは、前節に述べたGit Flow機能もサポートしていて、複雑なバージョン管理操作を直観的なGUI で行えるようになっている（図4.4参照）。


４．GitHub

4.4 SourceTree（続き）

図4.4 SourceTree によるGit Flow サポート機能メニュー（参考文献10））


４．GitHub

4.5 Gerrit

Gerritは、Googleが開発したGit用ソースコードレビューツールである。Android上のAp開発者を中心に普及しつつある

Gerritの主要な機能は次の通りである。① Git を用いたソースコード変更の変更差分を分かり易い形式で表示する。

② この変更差分の妥当性をコミットする前にパートナーに転送して、レビューを受ける。

③ さらには、正しく動作することをCIサーバでテストする。④ 上記の②③を確認したうえでCIサーバでマージして正式にコミットする。具体的には、自分自身でのテストと、パートナーによるレビューを完了したものだけを、ＪｅｎｋｉｎｓなどのCI ツールに渡して、メインファイルと統合する。

Gerritを日常作業の中に取り込むことにより、ソースコード更新の信頼性が大きく改善されると評判になっている。


５．GitHubとCIツールの連携

GitHubは、他のツールと直接的な連携をする場合もあるが、多くの場合に、CI(Continuous Integration)ツールを介して、間接的に他のツールと連携する。以下では、ＣＩツールの代表としてJenkinsとTravis

CI の二つについてGitHubとの連携方法を解説する。

5.1 Jenkinsとの連携CIツールは、その基本的な機能を実現するうえで変更歴管理・バージョン管理ツールと密接に連携する必要がある。Jenkinsにおいては、主要な連携相手はSubversionであり続けてきた。しかし、最近になって、Git もSubversionの連携相手の標準メニューに組入れられるようになってきた。したがってまた、GitHubとJenkinsの連携は極めて安定した関係に成熟してきたということが出来る。図5.1 にGitHubとJenkinsの連携の例を示す。GitHubに新しいん変更がpushされると、これがJenkinsに知らされる。Jenkinsは、その変更内容を受け取り、変更に対応したテストを自動起動する。


５．GitHubとCIツールの連動

5.1 Jenkinsとの連携（続き）

図5.1 GitHubとJenkinsの連携の例（参考文献１４））


５．GitHubとCIツールの連動

5.2 Travis CI との連携Travis CI はオープンソースコミュニティのためにホストされたCI

サービスである。Travis CI は、当初はRuby, PHP, JavaScript 等のWeb開発者を中心に普及していったが、最近ではこれらを越えて利用され普及が進んでいる。クラウド上のSoftware Engineering Service と言うことで、GitHub と

Travis CI は、本質的に相性が良い。GitHubとTravis CI を連動させるためには、GitHubに .travis.yml というTravis CI 用のファイルを用意する。 .travis.yml では次の情報を定義する。①使用する言語 ②バージョン ③テストを実行するコマンド例えば、バージョンを複数記述すると、Travis CI はこれらのバージョンに対するテストを連続して実行してくれる。

Travis CI は、テストの進捗状況、テスト結果等をグラフィカルに表示するので、作業管理が容易になると好評である。また、初期設定などは、Jenkins よりも楽であるという人もある。


６．まとめ

１）情報システムの大規模化・複雑化・分散開発化が進んでいる。世界的なレベルでの標準部品化・標準パターン化・標準フレームワーク化・クラウド化がこれをさらに加速している。

２）これらの課題に対処するためにソフトウェア変更歴管理・バージョン管理を中心としたソフトウェア構成管理が必須になってきている。－誤りのないソフトウェア資産（リソース）管理－ソフトウェア開発の高度な自動化の推進

３）ソフトウェア開発の自動化は、個別プロセスの自動化にとどまらず、複数の関連プロセスを連携させる統合的、システム的な自動化が期待されている。GitHubはこれら自動化ツールの連携のHub、として機能していくものと期待されている。

４）独立したツールとしてのGit, GitHubを評価すると、まずはその優れた性能があげられる。Subversion比で１～２桁の高い性能が得られる。また、ブランチを作成して管理するための操作性、性能が他の同種ツールと比べて格段に高い。そして、多様なバージョンを並行して作成し、管理していく支援機能において優れている。


６．まとめ（続き）

５）また、GitHubは、アジャイル開発におけるチーム開発、すなわち個人による開発ではなく、チームメンバーが相互に協力しながら開発していくことを促進する。これは、メンバー各人の能力アップ、したがってチーム全体の能力アップに大きく寄与する。結果として、開発効率の向上、開発工期の短縮に大きな効果をもたらす。

６）総合的に見ると、GitHubによる変更歴管理・バージョン管理は次のように階層化されている。（図6.1を参照）①作業領域（ワークツリー）上での変更②上記を”commit”することによるローカルリポジトリ上での変更③上記を”push”することによるセントラルリポジトリ上での変更④Git Flowによる複数バージョン間の管理


６．まとめ

セントラルリポジトリ―

ローカルリポジトリ―

ワークツリー（作業コピー）

checkout commit

pull/

fetchpush

master develop feature

branches

hotfixesrelease

branches

(Version Flow)

図6.1 GitHubにおける変更歴管理・バージョン管理の階層


＜付録＞Gitの代表的なコマンド

コマンド名機能

add ファイルの内容のインデックスへの追加

bisect バグを持ち込んだ変更の二分探索

blanch ブランチの列挙、作成、削除

checkout チェックアウトとブランチの切り替え

clone 新しいディレクトリへのリポジトリの複製

commit リポジトリへの変更の記録

diff コミット間やコミットとディレクトリ間等の変更の表示

fetch 他のリポジトリからのオブジェクトやリファランスの取得

grep 指定したパターンにマッチする業の表示

init 空のGitリポジトリの生成、または既存のリポジトリの再初期化

log コミットログの表示

merge 複数の開発履歴（コミット）の結合

表A1-1 Git の代表的なコマンド（１）


＜付録＞Gitの代表的なコマンド

コマンド名機能

mv ファイル、ディレクトリ、シンボリックリンクの移動または名前の変更

pull 他のリポジトリやローカルブランチからの取得とマージ

push リモートのリファレンスを関連するオブジェクトと共に更新

rebase ローカルコミットの上流の更新の先頭に合わせた前方移植

reset 現在のHEADの指定した状態へのリセット

rm ファイルの作業ツリーとインデックスからの削除

show 様々な型のオブジェクトの表示

status 作業ディレクトリの状態の表示

tag GPG署名されたタグオブジェクトの作成、列挙、削除または検証

表A1-2 Git の代表的なコマンド（２）

参考文献５）より転載


1) “Continuous Integration” P. M. Duvall, S. M. Matyas, A. Glover

2007 by Pearson Education, Inc. 「継続的インテグレーション入門」（訳）大塚庸司、丸山大輔、岡本裕二、亀村圭助２００９年日系ＢＰ社

2) “Continuous Delivery: reliable software releases through build,test and

deployment automation” Jez Humble, David Farley 2010 Addison-Wesley

3) “Version Control with Subversion Second Edition” C. Michael Pilato, Ben

Collins-Sussman, Brian W. Fitzpatrick 2009 O’Reilly

「実用Subversion 第２版」宮本久二男（監訳）、朝枝雅子、浜本階生（訳）２００９年オライリージャパン

4) “Pragmatic Version Control Using Subversion 2nd Edition” Mike Mason 2006

「Subversion実践入門：達人プログラマに学ぶバージョン管理第２版」でびあんぐる（監訳）２０１１年オーム社

5) “Version Control with Git” Jon Loeliger 2009 O’Reilly 「実用Git」吉藤英明（監訳）、本間雅洋、渡邊健太郎、浜本階生（訳）２０１０年オライリージャパン

6) 「入門Git」濱野純（著）２００９年秀和システム7) “Pragmatic Version Control Using Git” Travis Swicegood 2008

「入門git」でびあんぐる（監訳）２００９年オーム社


8) “A successful Git branching model” By Vincent Driessen Jan 2010

http://nvie.com/posts/a-successful-git-branching-model/

9) 「GitHub実践入門」大塚弘記（著）２０１４年技術評論社10) 「これでGitも怖くない！ GUIでのバージョン管理が無料でできるSourceTreeの7

つの特徴とは」岡本隆史２０１３年http://www.atmarkit.co.jp/ait/articles/1310/15/news019.html

11) 「Git&GitHub入門」岡本隆史、大塚弘記（著） Software Design ２０１５年６月号技術評論社

12) 「開発ツール徹底攻略～Git, GitHub～」２０１３年５月技術評論社13) Git-Official Site http://www.git-scm. all-and-fast com/about/sm

14) 「継続的インテグレーションのススメ Jenkinsでテスト結果を表示」２０１３年 by megadreams http://megadreams14.com/?p=27

http://nvie.com/posts/a-successful-git-branching-model/

http://www.atmarkit.co.jp/ait/articles/1310/15/news019.html

http://www.git-scm.com/about/small-and-fast

http://www.git-scm.com/about/small-and-fast

http://megadreams14.com/?p=27