Download - はこだてIKA夜間勉強会 バージョン管理#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以外にも追加しておきます
バージョンとは
• 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 に作った初版。日付をつけた。
人力バージョン管理
index.html.201302012/1 に作った初版。日付をつけた。
2/1 に作った第2版。日付だとかぶるので少し変化。
index.html.20130201_02
人力バージョン管理
index.html.201302012/1 に作った初版。日付をつけた。
2/1 に作った第2版。日付だとかぶるので少し変化。
index.html.20130201_02
直前のバージョン。安易に .bak にリネームした。 index.html.bak
人力バージョン管理
index.html.201302012/1 に作った初版。日付をつけた。
2/1 に作った第2版。日付だとかぶるので少し変化。
index.html.20130201_02
直前のバージョン。安易に .bak にリネームした。 index.html.bak
最新版 index.html
問題点バージョンの表見規則の人依存
• バージョンの表現規則が人依存
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• 人依存なのでファイルごとにばらばらになったりする
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• 人依存なのでファイルごとにばらばらになったりする• index.html.01
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• 人依存なのでファイルごとにばらばらになったりする• index.html.01• index.css.20130201
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• 人依存なのでファイルごとにばらばらになったりする• index.html.01• index.css.20130201• main.js.test
• バージョンの表現規則が人依存• 日付(YYYYMMDDなど)• 人力インクリメント(_01, _02など)• 合わせ技(YYYYMMDD_01など)
• 人依存なのでファイルごとにばらばらになったりする• 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
• ファイル単位• index.html.01• index.css.20130201• main.js.test
• ディレクトリ単位
• ファイル単位• index.html.01• index.css.20130201• main.js.test
• ディレクトリ単位• images.bak/
• ファイル単位• index.html.01• index.css.20130201• main.js.test
• ディレクトリ単位• images.bak/• js.old/
• ファイル単位• index.html.01• index.css.20130201• main.js.test
• ディレクトリ単位• images.bak/• js.old/• css/20130201/
• ファイル単位• index.html.01• index.css.20130201• main.js.test
• ディレクトリ単位• images.bak/• js.old/• css/20130201/
★バージョンの管理単位がばらばら★特定のバージョンに一括で戻すのが困難★リリース後バグが判明したので切り戻したい★過去のリリースバージョンを参照したい
問題点安全に共有できない
• ファイルサーバで共有
• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge
• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge
• 共有場所: ¥¥Server¥project¥hoge
• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge
• 共有場所: ¥¥Server¥project¥hoge
• 共有タイミングが人依存
• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge
• 共有場所: ¥¥Server¥project¥hoge
• 共有タイミングが人依存• 同時編集の可能性
• ファイルサーバで共有• 自分の作業場所: C:¥project¥hoge
• 共有場所: ¥¥Server¥project¥hoge
• 共有タイミングが人依存• 同時編集の可能性
★複数人の作業では共有が困難★Aさんの変更が、 Bさんによって上書きされてしまうリスク★ソースコードが壊れてしまうリスク
問題点履歴管理が困難
• コメントで履歴管理
• コメントで履歴管理• <!-- 2013/02/03 skomatsu
スライドショーを追加 -->
• コメントで履歴管理• <!-- 2013/02/03 skomatsu
スライドショーを追加 -->
• <!-- 2013/02/04 ishikawa スライドショーを修正 -->
• コメントで履歴管理• <!-- 2013/02/03 skomatsu
スライドショーを追加 -->
• <!-- 2013/02/04 ishikawa スライドショーを修正 -->
• <!-- 2013/02/05 matsudate 下記バグあり。コメントアウト -->
• コメントで履歴管理• <!-- 2013/02/03 skomatsu
スライドショーを追加 -->
• <!-- 2013/02/04 ishikawa スライドショーを修正 -->
• <!-- 2013/02/05 matsudate 下記バグあり。コメントアウト -->
★履歴管理がカオスに★差分なんて見れたものではない★誰が、いつ、何の変更をしたか、が不明確
問題点作業分岐が困難
• 保守チーム
• 保守チーム• バグフィックスなどの修正
• 保守チーム• バグフィックスなどの修正
• 新機能A開発チーム
• 保守チーム• バグフィックスなどの修正
• 新機能A開発チーム• 機能追加開発
• 保守チーム• バグフィックスなどの修正
• 新機能A開発チーム• 機能追加開発
• 新機能B開発チーム
• 保守チーム• バグフィックスなどの修正
• 新機能A開発チーム• 機能追加開発
• 新機能B開発チーム• Aチームとは別の機能追加開発
• 保守チーム• バグフィックスなどの修正
• 新機能A開発チーム• 機能追加開発
• 新機能B開発チーム• Aチームとは別の機能追加開発
★複数チームが同時開発すると、 バッティングすることがあるので、 コードベースを分けたい★分けて開発★一本化しようとしたら、マージ地獄★マージし終わっても、あとから見ると出生不明
バージョン管理システム
• 略してVCS(Version Control System)
• ソース管理(SCM)とも言う
利点
利点
• バージョン管理規則は使用するVCSまかせ
利点
• バージョン管理規則は使用するVCSまかせ
• 複数人作業を手厚くサポート
利点
• バージョン管理規則は使用するVCSまかせ
• 複数人作業を手厚くサポート
• 履歴管理、閲覧、差分取得が容易
利点
• バージョン管理規則は使用する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.チェックアウト/アップデート
• 作業ディレクトリに最新版を取得
基本的な使い方1.チェックアウト/アップデート
• 作業ディレクトリに最新版を取得
2.変更• 作業ディレクトリ内のファイルを修正
基本的な使い方1.チェックアウト/アップデート
• 作業ディレクトリに最新版を取得
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. チェックアウト
1. チェックアウト
• チェックアウトに必要なもの
1. チェックアウト
• チェックアウトに必要なもの• URL
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...• file://...
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...• file://...
• (ユーザ)
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...• file://...
• (ユーザ)• (パスワード)
URL?サーバが必要?
YESおおむね、必要。
が、無くてもできる。
file://...ローカルディレクトリや、
共有ディレクトリに使える。
今からバージョン管理始めるなら
とりあえず file://... で始めるのが楽
→ あとからサーバ移行もできる
Windows しかないならTortoiseSVN で全部完結
なので
バージョン管理していないなら明日からすぐ!
TortoiseSVNの良い良い参考サイト紹介
http://techblog.yahoo.co.jp/tips/subversion-for-designers-01/
http://techblog.yahoo.co.jp/tips/subversion-for-designers-02/
もうファイル管理で困らない! デザイナーのためのSubversion/TortoiseSVN入門
デザイナーのためのSubversion/TortoiseSVN入門2 -Subversionでのフォルダーの命名・構成とTortoiseSVNの便利な使い方-
http://d.hatena.ne.jp/sinsoku/20100405/1270397683TortoiseSVNの基本的な使い方 その1
TortoiseSVNの良い良い参考サイト紹介
http://techblog.yahoo.co.jp/tips/subversion-for-designers-01/
http://techblog.yahoo.co.jp/tips/subversion-for-designers-02/
もうファイル管理で困らない! デザイナーのためのSubversion/TortoiseSVN入門
デザイナーのためのSubversion/TortoiseSVN入門2 -Subversionでのフォルダーの命名・構成とTortoiseSVNの便利な使い方-
http://d.hatena.ne.jp/sinsoku/20100405/1270397683TortoiseSVNの基本的な使い方 その1
Google Code の Wiki にリンク集として掲載してます
1. チェックアウト脱線
したので再掲
1. チェックアウト
• チェックアウトに必要なもの
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...• file://...
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
• https://...• svn://...• file://...
• (ユーザ)
脱線したので再掲
1. チェックアウト
• チェックアウトに必要なもの• URL
• 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 パースペクティブを選択
(1) sample-web を右クリック
(2) Team を選択
(3) リソース・ヒストリーを表示 をクリック
リビジョン履歴が表示される
リビジョン履歴が表示される
該当リビジョンでの変更ファイル
5. さらに変更を加える
5. さらに変更を加える
• 追加したファイル(testN.html)に、何か変更を加えてください
5. さらに変更を加える
• 追加したファイル(testN.html)に、何か変更を加えてください• <p>一行追加</p> みたいなのでいいです
(1) 何か変更する
(2) 変更があることを意味する「>」印がつく
(1) sample-web を右クリック
(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 を活用した例、バックアップなどの運用ノウハウなど聞きたい方が居れば、リクエストください。
• お疲れさまでした。