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

1Copyright (C) Masanori Kataoka. All Rights Reserved.
ソフトウェア変更管理・バージョン管理技術
～ GitとGitHub～
２０１５年８月２５日
片岡雅憲
2015/8/26
1
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
Commit
Images(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.5
21.0(*)
14.0 0.1x
1x(*)
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
３）ワークツリー(Work Tree)とインデックス（Index) （続き）
ワークツリー上の変更には多様な作業が混在しうる。例えば、
新しい機能を開発中に、ベースとする
ソースコードの中に不良を発見して
その修正も行ったとする。この新機能
の開発のための変更と不良修正の
ための変更を一つの同じ”commit”
で更新することは混乱を招く。
インデックスを介して、この二つの変更
を切り分けて別の”commit”とする必要
がある。
ワークツリー上の変更のすべてを
ひとまとめのものとして”commit”する
場合には、”commit –all”により、インデックスを経由なしで出来る。
ローカル
ディレクトリ
ワーク
ツリー
インデック
ス
“add”
“commit”
“commit
--all”
図3.2 インデックスによる
ステージング

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

３．Git
セントラル
リポジトリ―
ローカル
リポジトリ―
ワークツリ
ー（作業
コピー）
checkout commit
pull/
fetch
push
４）上位リポジトリとの同期
分散管理をしているために、必要に応じて上位のセントラルリポジト
リに自分の変更を反映する必要があり、これは”push”により行われ
また、逆に上位のリポジトリの変更を取り込
む必要があり、これは、”fetch”で行われ、
取り込んだ変更と自分の変更とを”merge”
する。”pull”により、”fetch”と”merge”を同時
に行うことが出来る。
図3.3 ローカルリポジトリ―と
セントラルリポジトリ―の同期

３．Git
５）タグとブランチ
プロジェクトがあるマイルストーンに達した時に、その時のリポジトリ
の状態に対して分かりやすいタグをつけられる。
また、分岐をした時はそれにブランチ名を付けられる。
（注）タグとブランチの詳細については、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
２）直観的なコミット単位の選択
Gitでは、図3.2に示すようにワークツリーとディレクトリの間にイン
デックスが介在し、ステージングが行われる。ソースコードのどの部
分がこのうちのどこに存在するのかの管理が煩わしい。SourceTree
では、①Working Copy Changes ②Staged Changes
③Uncommitted changes ボタンを押下すればこれらを明示してく
れる。
３）簡単なMerge操作
前記１）のcommit履歴グラフ上でmerge対象範囲をグラフィカルに
指定できる。
４）直観的なrebase
ブランチの分岐元を付け替えるrebaseは、分かりづらい操作である。
SourceTreeでは、と同様にcommitグラフからrebaseするブランチの
commitを選択するだけで、commitの分岐元を付け替えられる。

４．GitHub
５） CherryPick操作が容易
他のブランチのcommitをカレントブランチへmergeするCherryPick
操作もcommit履歴グラフ上で簡単に指定できる。
６）セントラルリポジトリとの同期
SourceTreeは、リモートブランチの自動フェッチ機能を持っており、
セントラルリポジトリの変更があった場合に、これをローカルリポジト
リ上で作業中に簡単に把握出来る。
７） Git Flow機能のサポート
SourceTreeは、前節に述べたGit Flow機能もサポートしていて、複
雑なバージョン管理操作を直観的なGUI で行えるようになっている
（図4.4参照）。

４．GitHub
図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/
fetch
push
master develop feature
branches
hotfixes
release
branches
(Version Flow)
図6.1 GitHubにおける変更歴管理・
バージョン管理の階層

コマンド名機能
add ファイルの内容のインデックスへの追加
bisect バグを持ち込んだ変更の二分探索
blanch ブランチの列挙、作成、削除
checkout チェックアウトとブランチの切り替え
clone 新しいディレクトリへのリポジトリの複製
commit リポジトリへの変更の記録
diff コミット間やコミットとディレクトリ間等の変更の表示
fetch 他のリポジトリからのオブジェクトやリファランスの取得
grep 指定したパターンにマッチする業の表示
init 空のGitリポジトリの生成、または既存のリポジトリの再初期化
log コミットログの表示
merge 複数の開発履歴（コミット）の結合
表A1-1 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

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

Recommended

Recommended

More Related Content

Similar to Agileツール適合化分科会（gitとgit hub）

Similar to Agileツール適合化分科会（gitとgit hub） (20)

More from masanori kataoka

More from masanori kataoka (16)

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