バージョン管理#01 -Subversion編-

はこだてIKA 夜間勉強会

バージョン管理- Subversion 編 -

skomatsufacebook.com/comutt, @comutt, id:comutt

atWare, Inc.February 28, 2013

必要なもの

• ネットワークに接続できるPC/Mac

• Subversive プラグイン導入済 Eclipse

• Google Code にアクセスするためのGoogle アカウント

Google Code

• URL: https://code.google.com/p/vcs01-svn/

• Wiki:

• https://code.google.com/p/vcs01-svn/wiki/VCS01

• https://code.google.com/p/vcs01-svn/wiki/SubversionLinks

• リンク集は、TortoiseSVN以外にも追加しておきます

https://code.google.com/p/vcs01-svn/

https://code.google.com/p/vcs01-svn/

https://code.google.com/p/vcs01-svn/wiki/VCS01




https://code.google.com/p/vcs01-svn/wiki/SubversionLinks




バージョンとは

• Ver. 1.2 や Rev. 3 など

• コンテンツの「状態」を一意に表すID

<html></html>

ver.1

<html></html>

ver.1

<html><body></body></html>

ver.2

<html></html>

ver.1

<html><body></body></html>

ver.2

<html><body> <h1>HTML</h1></body></html>

ver.3

原則

• コンテンツの状態が変化すると、バージョンが変化する

• バージョンは、一意のID

バージョン管理とは

• コンテンツのバージョンを管理する

人力バージョン管理


index.html.201302012/1 に作った初版。日付をつけた。



2/1 に作った第2版。日付だとかぶるので少し変化。

index.html.20130201_02





直前のバージョン。安易に .bak にリネームした。 index.html.bak





直前のバージョン。安易に .bak にリネームした。 index.html.bak

最新版 index.html

問題点バージョンの表見規則の人依存

• バージョンの表現規則が人依存

• バージョンの表現規則が人依存• 日付（YYYYMMDDなど）

• バージョンの表現規則が人依存• 日付（YYYYMMDDなど）• 人力インクリメント（_01, _02など）

• バージョンの表現規則が人依存• 日付（YYYYMMDDなど）• 人力インクリメント（_01, _02など）• 合わせ技（YYYYMMDD_01など）


• 人依存なのでファイルごとにばらばらになったりする


• 人依存なのでファイルごとにばらばらになったりする• index.html.01


• 人依存なのでファイルごとにばらばらになったりする• index.html.01• index.css.20130201


• 人依存なのでファイルごとにばらばらになったりする• index.html.01• index.css.20130201• main.js.test


• 人依存なのでファイルごとにばらばらになったりする• index.html.01• index.css.20130201• main.js.test

★複数人の作業で人数が増えるほどカオスに★統一を図るのは不可能

問題点バージョンの「単位」が人依存

• ファイル単位

• ファイル単位• index.html.01

• ファイル単位• index.html.01• index.css.20130201

• ファイル単位• index.html.01• index.css.20130201• main.js.test


• ディレクトリ単位


• ディレクトリ単位• images.bak/


• ディレクトリ単位• images.bak/• js.old/


• ディレクトリ単位• images.bak/• js.old/• css/20130201/


• ディレクトリ単位• images.bak/• js.old/• css/20130201/

★バージョンの管理単位がばらばら★特定のバージョンに一括で戻すのが困難★リリース後バグが判明したので切り戻したい★過去のリリースバージョンを参照したい

問題点安全に共有できない

• ファイルサーバで共有

• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge


• 共有場所: ¥¥Server¥project¥hoge



• 共有タイミングが人依存



• 共有タイミングが人依存• 同時編集の可能性



• 共有タイミングが人依存• 同時編集の可能性

★複数人の作業では共有が困難★Aさんの変更が、 Bさんによって上書きされてしまうリスク★ソースコードが壊れてしまうリスク

問題点履歴管理が困難

• コメントで履歴管理

• コメントで履歴管理• 



• 




• 




• 

★履歴管理がカオスに★差分なんて見れたものではない★誰が、いつ、何の変更をしたか、が不明確

問題点作業分岐が困難

• 保守チーム

• 保守チーム• バグフィックスなどの修正


• 新機能A開発チーム


• 新機能A開発チーム• 機能追加開発



• 新機能B開発チーム



• 新機能B開発チーム• Aチームとは別の機能追加開発



• 新機能B開発チーム• Aチームとは別の機能追加開発

★複数チームが同時開発すると、バッティングすることがあるので、コードベースを分けたい★分けて開発★一本化しようとしたら、マージ地獄★マージし終わっても、あとから見ると出生不明

バージョン管理システム

• 略してVCS（Version Control System）

• ソース管理（SCM）とも言う

利点

利点

• バージョン管理規則は使用するVCSまかせ

利点


• 複数人作業を手厚くサポート

利点



• 履歴管理、閲覧、差分取得が容易

利点



• 履歴管理、閲覧、差分取得が容易

• 作業分岐、再統合が容易

使っていないなら明日からすぐ使って下さい

種類

• 集中管理型

ref: http://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_1.html

種類

• 分散型

ref: http://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_1.html

種類

種類

• 集中管理型（一例）• フリー: Subversion, CVS

• 商用: Perforce, Team Foundation Server Clear Case, Visual SourceSafe

種類

• 集中管理型（一例）• フリー: Subversion, CVS

• 商用: Perforce, Team Foundation Server Clear Case, Visual SourceSafe

• 分散型（一例）• フリー: Git, Mercurial, Bazaar, Monotone

• 商用: BitKeeper, Code Co-op, Synergy

Subversion集中管理型リポジトリのデファクトスタンダード

仕組み

作業コピーリポジトリ

仕組み

①（最新版）取得作業コピーリポジトリ

仕組み

②変更


仕組み

②変更

③登録


仕組み

②変更

③登録

①（最新版）取得

• 登録・・・コミット


仕組み

②変更

③登録

①（最新版）取得

• 登録・・・コミット

• 取得・・・チェックアウト、アップデート


基本的な使い方

基本的な使い方1.チェックアウト／アップデート

• 作業ディレクトリに最新版を取得



2.変更• 作業ディレクトリ内のファイルを修正



2.変更• 作業ディレクトリ内のファイルを修正

3.コミット• 作業ディレクトリ内のファイルをリポジトリに登録

リポジトリ

• コンテンツが履歴管理されている

リポジトリ

• コンテンツが履歴管理されている

• 変更をコミットすると、自動的にバージョン（リビジョン）が上がる

リポジトリ

作業コピー

• リポジトリと紐付いたローカルディレクトリ

作業コピー

• リポジトリと紐付いたローカルディレクトリ• リポジトリに意図的にコミットするまで、コンテンツは同期されない

作業コピー


• コミットせずに取り消すこともできる

作業コピー


• コミットせずに取り消すこともできる• 作業コピーを消しても、リポジトリは消えない

作業コピー

Subversionとは• 元々 CollabNet, Inc. が開発したVCS

• CVSの置き換えを狙って作られた

• 2010年にApacheトッププロジェクト

• Apacheライセンス（オープンソース）

• Win/Mac/Linux など、幅広いプラットフォームで動作

GUIクライアント

• Windows

• TortoiseSVN など

• Mac

• Versions, Cornerstone など

• Linux

• Esvn, RabbitVCS など

IDE連携

• バージョン管理連携機能がついたIDEでは、Subversionは対応済みのことが多い

• Eclipse

• Visual Studio

• Xcode

• etc..

Subversion 初歩

1. チェックアウト


• チェックアウトに必要なもの


• チェックアウトに必要なもの• URL



• https://...



• https://...• svn://...



• https://...• svn://...• file://...



• https://...• svn://...• file://...

• （ユーザ）



• https://...• svn://...• file://...

• （ユーザ）• （パスワード）

URL?サーバが必要？

YESおおむね、必要。

が、無くてもできる。

file://...ローカルディレクトリや、

共有ディレクトリに使える。

今からバージョン管理始めるなら

とりあえず file://... で始めるのが楽

→ あとからサーバ移行もできる

Windows しかないならTortoiseSVN で全部完結

なので

バージョン管理していないなら明日からすぐ！

TortoiseSVNの良い良い参考サイト紹介

http://techblog.yahoo.co.jp/tips/subversion-for-designers-01/


もうファイル管理で困らない！　デザイナーのためのSubversion/TortoiseSVN入門

デザイナーのためのSubversion/TortoiseSVN入門2 -Subversionでのフォルダーの命名・構成とTortoiseSVNの便利な使い方-

http://d.hatena.ne.jp/sinsoku/20100405/1270397683TortoiseSVNの基本的な使い方その1





http://d.hatena.ne.jp/sinsoku/20100405/1270397683




TortoiseSVNの良い良い参考サイト紹介



もうファイル管理で困らない！　デザイナーのためのSubversion/TortoiseSVN入門

デザイナーのためのSubversion/TortoiseSVN入門2 -Subversionでのフォルダーの命名・構成とTortoiseSVNの便利な使い方-

http://d.hatena.ne.jp/sinsoku/20100405/1270397683TortoiseSVNの基本的な使い方その1

Google Code の Wiki にリンク集として掲載してます









1. チェックアウト脱線

したので再掲


• チェックアウトに必要なもの

脱線したので再掲






• https://...




• https://...• svn://...




• https://...• svn://...• file://...




• https://...• svn://...• file://...

• （ユーザ）




• https://...• svn://...• file://...

• （ユーザ）• （パスワード）


皆さんにはすでにしていただきました

作業コピーを見てみよう

• 手順通りにチェックアウトしたなら

• Windows の方

• C:¥tech-study¥workspace¥sample-web

• Mac の方

• ~/Documents/tech-study/workspace/sample-web



★.svn ディレクトリがある = 作業コピー（OSの設定によっては表示されません）

2. 変更

2. 変更

• Eclipse で、それぞれHTMLファイルを作成してください

2. 変更

• Eclipse で、それぞれHTMLファイルを作成してください

• testN.html （Nは数字）というファイル名で作成してください

(1) public_html の上で右クリック

(2) New をクリック

(3) File をクリック

(1) ファイル名を入力

(2) Finish をクリック

? がついてる= まだバージョン管理されていない

なにか、適当なHTMLを入力して保存してください

3. コミット

3. コミット

• 作成したHTMLをコミットしてください

(1) sample-web を右クリック

(2) Team をクリック

(3) リポジトリーと同期をクリック

(1) + アイコンでツリーを展開

(2) 新たに test0.html をバージョン管理下におくことを意味する

(3) 赤い方の矢印をクリックしてコミット

(1) コミットメッセージを入力

(2) 自分が作成したファイルが追加対象になってることを確認

(3) OKをクリック

コミットメッセージ?

なにそれおいしいの？

無いと困る

コミットメッセージ


• コミット時に、任意のコメントを書ける


• コミット時に、任意のコメントを書ける• そのコミットが、何の意図を持ってしたのかなどをコメントする


• コミット時に、任意のコメントを書ける• そのコミットが、何の意図を持ってしたのかなどをコメントする• 後から履歴を追うときに大変重要


• コミット時に、任意のコメントを書ける• そのコミットが、何の意図を持ってしたのかなどをコメントする• 後から履歴を追うときに大変重要• コミットメッセージがないと、「この変更は何なの？」となりやすい

コミットメッセージの例


• BUG xxx を修正


• BUG xxx を修正• ストーリー yyy を実装


• BUG xxx を修正• ストーリー yyy を実装• チケット zzz を完了


• BUG xxx を修正• ストーリー yyy を実装• チケット zzz を完了• ○○を実装。実はまだ△△機能がIEで動かない。


• BUG xxx を修正• ストーリー yyy を実装• チケット zzz を完了• ○○を実装。実はまだ△△機能がIEで動かない。

補足情報もいれると、コミットログの情報量が増えて良い

4. 履歴を見る

4. 履歴を見る

• Eclipse で、 sample-web プロジェクトの履歴を確認してください

(1) Java パースペクティブを選択


(2) Team を選択

(3) リソース・ヒストリーを表示をクリック

リビジョン履歴が表示される

リビジョン履歴が表示される

該当リビジョンでの変更ファイル

5. さらに変更を加える


• 追加したファイル（testN.html）に、何か変更を加えてください


• 追加したファイル（testN.html）に、何か変更を加えてください• <p>一行追加</p> みたいなのでいいです

(1) 何か変更する

(2) 変更があることを意味する「＞」印がつく


(2) Team をクリック

(3) リポジトリーと同期をクリック

(1) ツリーを展開

(2) コミット可能な変更があることを意味する「→」マークがついている

(3) sample.html をダブルクリックする

ローカルファイルの状態

リポジトリ最新の状態

リポジトリ最新に比べて、一行追加されている

コミットボタンをクリック

コミットメッセージの入力

OKをクリック

6. 差分を見る

• 追加した testN.html を右クリックし、Team -> リソース・ヒストリーを表示をクリックしてください

• 選択したリビジョン間の差分を見ることができます• 比較したいリビジョンをCtrl/Cmdを押しながら選択

• Compare with Each Other

一歩進んだバージョン管理

ブランチ

• 日本語訳: 枝

• ソースコードを枝分かれさせたいとき

• 機能単位、作業単位で枝分けしたりする

• メインの枝は幹（trunk）

Subversion でのブランチ• 以下のようなツリー構造が推奨されている

• branches 配下に、各ブランチを格納

リポジトリ├── trunk│ └── trunk のソースコード└── branches ├── branch1 │ └── branch1 のソースコード └── branch2 └── branch2 のソースコード

タグ

• 洋服などについてる「タグ」と同じ意味

• ラベルとも言える

• 特定のバージョンに名前を付けたいときに使う

Subversion でのタグ• 以下のようなツリー構造が推奨されている

• tags 配下に、各タグを格納

リポジトリ├── trunk│ └── trunk のソースコード└── tags ├── tag1 │ └── tag1 のソースコード └── tag2 └── tag2 のソースコード

ブランチの活用例1

• trunkはメインストリーム版

• branchはベータ版

ブランチの活用例2

• trunkはFIXしたソースコードのみ

• 開発はすべてbranchで行う

• 開発完了したbranchはtrunkにマージする

弊社での例

• trunk・・・メインストリーム、FIX済み専用

• branch・・・機能ごと、BUGFIXごとにブランチ

• tag・・・リリースバージョンごとにタグ

リポジトリ├── trunk├── branches│ ├── redmine-1│ ├── redmine-2│ └── redmine-3└── tags ├── release-1.0.0 ├── release-1.0.1 └── release-1.1.0

• チケット駆動開発• どのブランチでどの機能開発・BUGFIXをしているか一目瞭然

• ソースが混在しない

おわり

• 2時間でハンズオン混みで、Subversion によるバージョン管理の魅力をお伝えするのはなかなか難しいですね（私の講師力が低いとも）。

• Git編もやりたいのですが、それよりももっと Subversion を活用した例、バックアップなどの運用ノウハウなど聞きたい方が居れば、リクエストください。

• お疲れさまでした。

Technology

バージョン管理#01 -Subversion編-