バージョン管理システム（VCS）の紹介と集中VCSと分散VCSの違い。gitコマンドの簡単な説明

1. Git 入門ちょい手前
後藤 祐一
埼玉大学 大学院理工学研究科
数理電子情報部門情報領域

2. 発表の流れ
• バージョン管理システムとは
• ブランチとブランチモデル
• 分散バージョン管理システム Git
2

3. バージョン管理システム
• バージョン管理システム（Version Control System, VCS)
コンピュータ上で作成、編集されるファイルの変更履歴を
管理するためのシステム [ja.wikipedia 2014.7.10]
• 以下のような状況を解決するソフトウェア
– 間違ってファイルを消してしまった
– 変更を保存した後に、変更前の方が良いことに気付いた
– 複数人でファイルを編集しているとき、どの変更を誰が
行ったのかわからない
• 代表的なバージョン管理システム
– 集中管理：RCS、CVS、Subversion
– 分散管理：Git、Mercurial
3

4. 変更履歴
編集１
l.2 (B, C)
l.3 (C, D)
l.4 (D, E)
A
B
C
D
Repository
リポジトリ
編集 A
C
D
E
編集 C
D
E
F
編集
編集2
l.1 (A, C)
l.2 (C, D)
l.3 (D, E)
l.4 (E, F)
格納
編集3
l.1 …
l.2 …
… …
… …
4

5. 集中VCS
File 1
Repository
リポジトリ
作業ディレクトリのファイル／ディレクトリの変更履歴を
リポジトリに保存するのが「コミット」
リポジトリから（変更履歴を反映させた）ファイルや
ディレクトリを取り出すのが「チェックアウト」（注）
File 1
File 1File 1
File 1File 1
作業ディレクトリ
（Working directory)
コミット
(commit)
チェックアウト
(checkout)
注：チェックアウトの動作はVCSごとに異なる 5

6. 集中VCSの例
• RCS (Revision Control System)
– 最初期のVCS
– Walter F. Tichyが1980年代に開発
• CVS (Concurrent Versions System)
– 1990年代に普及
– ネットワーク経由で利用できる最初期のVCS
• Subversion (略称：SVN)
– CVSの問題点を解決するために開発されたVCS
– CVSの後、Gitが普及する前まで広く使われていた
6

7. 分散VCS
Rep.
集中VCSと分散VCSの違いはリポジトリが１つなのか、
複数なのかの違い。分散VCSではリポジトリ間で
格納している変更履歴を同期をとることができる
ローカルリポジトリの変更履歴を
リモートへ送るのが「プッシュ」
その逆が「プル」
リモートリポジトリをローカルに
コピーするのが「クローン」
WorkDir 1 プッシュ
(push)
プル
(pull) 7
Rep.
Rep.
WorkDir 3
WorkDir 2
クローン
(clone)

8. Git
• 分散バージョン管理システムの一種
• Linux kernelのソースコード管理のために提案・開発されて
いるバージョン管理システム
• ここ2～3年ではもっともよく利用されている
• リポジトリ間の通信方式
– ファイルシステム（同一計算機上の場合）
– SSH (Secure Shell)
– Git専用プロトコル（認証機能なし）
– HTTP/HTTPS（WebDAV）（pushするためにはWebDAV
が必要）
• 集中VCSに比べて、ブランチ管理が圧倒的に行いやすい
8

9. 変更履歴の分岐（branch）（1/2）
< 1, 2, 3, 4>, <5, 6, 7>, <8> がそれぞれ分岐（branch ブランチ）
9
A
B
C
D
編集 A
C
D
E
C
D
E
F
C
D
E
F
A
B
D
E
A
B
D
F
A
B
D, F?
F, E?
A
B
F
E
分岐
分岐
合流
1 2 3 4
5 6 7
8
分岐させることを
「Branchを作る」ともいう

10. 変更履歴の分岐（branch）（2/2）
二つの変更履歴の分岐を合流させると衝突が起こることがある
10
A
B
D
E
A
B
D
F
A
B
D, F?
F, E?
A
B
F
E
分岐
合流
5 6 7
8
合流させることを
「マージ（merge)」という
A
B
D
F
E
9
６と８で衝突（conflict）が
発生している
解決
衝突が起こっている変更履歴
を直すことを解決という

11. 変更履歴の分岐の必要性
• 変更履歴を分岐させることで、複数人および複数バージョン
のソフトウェア開発を並行して進めることができる
• 基本となる分岐をマスターブランチ（master branch、省略し
てマスター）という
• ブランチをどのような約束で利用するのかのモデルを
ブランチモデル（branching model）という
• 有名なものとして以下のものがある
– git-flow [Driessen 2010]
– GitHub-flow [Chacon 2011]
11

12. ブランチモデルの基本発想
• 常に正常に動作するバージョンを用意しておく
• 現在公開しているバージョンを管理するためのソースコー
ドと、機能の追加、バグの修正のためのソースコードを
別々に管理する（つまり、ブランチを分ける）
• 何のためにソースコードの変更を行っているかがブランチ
名からわかるようにしておく
• 開発プロジェクトの目的や特徴、環境、メンバーの数や質
によって適切なブランチモデルは異なるので、既存のブラ
ンチモデルをそのまま使うのではなく、カスタマイズする
のが重要
12

13. git-flow
13
hotfixdevelop masterreleasefeature
2種類の恒久的ブランチ、3種類の一時的ブランチ
出典
[Driessen 2010]

14. GitHub flow
• 1種類の恒久的ブランチ (master) と作業内容を反映させた
任意個の一時的ブランチ（git-flow におけるhotfixとfeature
ブランチの役割）
• masterブランチへのマージの前にGitHubのプルリクエスト
という機能を使って、マージ対称の変更のレビューを行う
• レビュー後はmasterにマージし、即座に公開する
14

15. Git コマンド
Rep.
• リポジトリ：コメントおよび変更の履歴のデータセット
• 作業ツリー：現在作業しているディレクトリやファイル群
• インデックス：次のcommit で 変更を保存する対象ファイルのリスト
WorkDir 1
push
pull, fetch
15
Rep.
Rep.
WorkDir 3
WorkDir 2
clone
Index
作業ツリー
commit
add
checkout
branch, merge
mv, rm

16. 参考資料
[ja.wikipedia 2014.7.10] ja.wikipedia: バージョン管理システム,
2014.7.10 版,
https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%BC%E3%82%B8%
E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%82%B7%E3%
82%B9%E3%83%86%E3%83%A0
[Git] Git: https://git-scm.com/
[Driessen 2010] V. Driessen: A successful Git branching model,
http://nvie.com/posts/a-successful-git-branching-model/ ;
見えない力: A successful Git branching model を翻訳しました,
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-
model.html (上の翻訳）
[Chacon 2011] S. Chacon: GitHub Flow,
http://scottchacon.com/2011/08/31/github-flow.html ;
Gab-km: GitHub Flow (Japanese translation) ,
https://gist.github.com/Gab-km/3705015 （上の翻訳）
16