More Related Content
Similar to Tortoise hgのすすめ
Similar to Tortoise hgのすすめ (20)
Tortoise hgのすすめ
- 3. バージョン管理システムとは？
VCS: Version Control System
●
●
「バージョン管理システム」とは、コ
ンピュータ上で作成、編集されるファ
イルの変更履歴を管理するためのシス
テム。
特にソフトウェア開発において「ソー
スコードの管理」に用いられることが
多い。
Wikipedia 2013年4月13日 (土) 09:26 版より引用
2013/12/13 Rev.16
- 4. 代表的な VCS 一覧
CVS
VSS
(Visual Source
Safe)
Subversion
Git
Mercurial
初版
リリース
1990年
1994年
2000年
2005年
2005年
リポジトリ
方式
集中
集中
集中
分散
分散
※ リポジトリ : ソースコードの変更情報を記録したデータ
ベースのこと。
2013/12/13 Rev.16
- 17. 分散型 VCS の利点 (1)
●
ローカル PC にコミットできる
–
–
–
変更点を気軽にコミットできる
「集中型」で頻繁に発生する「他の人と
ソースコードの変更が衝突してコミット
できない・・・」という心配は無用
「コミット後にマージ」という使い方が
できる
●
マージ作業を何度でもやり直せる
2013/12/13 Rev.16
- 18. 分散型 VCS の利点 (2)
●
サーバとネットワークで接続されてい
ない状態でも動作
–
サーバへのアクセスが必要ないた
め・・・
● 変更履歴の閲覧
● ファイル内の変更部分の検索
・・・などの動作が速い
2013/12/13 Rev.16
- 19. 分散型 VCS の利点 (3)
●
ファイル経由でもリポジトリ同期が可
能
–
メールの送受信できれば、添付ファイル
経由でリビジョンの受け渡しが可能
2013/12/13 Rev.16
- 24. TortoiseHg のすゝめ (1)
●
CVS や Subversion など、既存の VCS
に動作が近い
–
●
Git は固有のクセが多い
シンプルなワークフロー
–
–
「名前なしブランチ」による平行開発
TortoiseHg(Mercurial)では「コミッ
ト」するだけで勝手にブランチします
2013/12/13 Rev.16
- 33. TortoiseHg のすゝめ (3)
●
Git にも実装されていない機能も
–
Large Files
●
–
Shelve
●
●
–
巨大なバイナリファイルはオンデマンドで取得
変更点を一時的に避けておいて、後で元に戻す
(2013年11月に実装された最新機能なので TortoiseHg
では、まだ使えません・・・)
TortoiseHg 固有の Shelve 機能は使えます
Changesets Evolution
●
「チェンジセットの削除」を別リポジトリに伝搬する
2013/12/13 Rev.16
- 46. 分散型 VCS が
開発された理由
●
●
Linux カーネルの開発過程で「大規模なソ
フトウェアを、複数の開発者で並行開発す
るための手法」が確立されていった。(2002
年～2005年)
Linux カーネルの開発で使用するために
「分散型 VCS」の開発(※1)が行われた
(2005年～)
–
「大規模なソフトウェアを、複数の開発者で並
行開発する」ために最良のツールが作成された
2013/12/13 Rev.16
Editor's Notes
- 代表的な バージョン管理ソフトの一覧。
この中のツールのうち、いずれかは、開発で使用したことがあると思います。
表の中の「リポジトリ」とは、管理対象となるソースコードの変更情報を記録したデータベースのこと。
この、リポジトリの方式により「集中型」と「分散型」２種類に分けられます。
- では、集中型のバージョン管理とはどのようなものか？
- ：
：
おそらく皆さんが業務で使用しているのは、こちらのタイプ。
いわゆるクライアント・サーバーモデル。
- 図にするとこんな感じ。
中央にリポジトリを格納したサーバがあり、開発者はこのサーバにアクセスしながら使用する形になります。
図中中央にあるのがリポジトリサーバ。
ちなみに、図中の「データベースのマーク」はリポジトリを示しています。
- 「集中型バージョン管理」の流れを順に説明しますが、
まず、ソースコードを取得する場合には、リポジトリからチェックアウトを行う。
- ソースを更新して、リポジトリに登録する場合にはサーバに対してコミット、（ツールによってはチェックイン）を行う。
サーバにある最新の変更を手元のソースに反映したい場合には、アップデートを行う。
これが集中型の流れになります。
- では、もう一方である分散型バージョン管理はどのようなものか？
- ：
：
- 図にするとこんな感じ。
開発者全員がリポジトリ（データベース）を保持して、サーバとしてもクライアントとしても動作できるので、矢印だらけになっている。
- 分散型バージョン管理では、まず、リポジトリを自分のPCにコピーします。これをクローンと呼びます。
- ソースコードを取り出す場合には、自分のPCのリポジトリから。
- ソースコードの変更をコミットする場合にも自分のＰＣのリポジトリに。
- コミットしたリビジョンを他のリポジトリとやり取りする場合には、プッシュとプルを使用して、リポジトリ間の同期を取ります。
- 分散型の利点を説明すると・・・：
：
：
分散型のツールは、変更をコミットしてから他の人と同期をとる形になるので、基本的に、コミット後にマージをする、使い方になります。
マージに失敗して元に戻したい場合、ソースをチェックアウトすれば何度でも元に戻れますので、
- ：
：
ちなみに、数百万行規模のソースコードを Subversion で運用してみたことがありますが、遅すぎて実用に堪えませんでした。
- ：
：
なので、＜次＞
- このように、別々のオフィスで開発を行っている場合でも、「バンドルファイル」というファイルを用いてリビジョンの受け渡しができます。
開発拠点が複数個所に分かれていても、各々で開発を進めて、定期的に成果物としてリビジョンをやり取りする・・という開発もやりやすい。
- これが、メインとなるTortiseHgのワークベンチ画面。
ここで画面を切り替えてデモ。
- ＴｏｒｔｏｉｓｅＨｇのどこがお勧めか？
というと、
- Ｒｅｖ．１ に対して、２人の開発者が別々の変更をコミットして、プルを行うとこの状態になります。
- ２人の開発者の変更をマージして、相応の変更を統合します。
- 「ブランチ」を用いることで、他の開発者の変更の影響を受けずに、開発を進めることができます。
で、この、「名前なしブランチ」にチームメンバが慣れてきたら、「名前付きブランチ」を使って、「ブランチパターン」を使った開発に移行させます。
そうすることによって、徐々に、平行開発を安全に進められるようにになります。
- このワークフローだと、ブランチを多用することになり、マージの頻度も多くなります。
マージに非常に多くの工数が必要なのではないかと？心配になると思います。
- 「リポジトリの全情報をローカルに持っている」ため、全てのリビジョンを参照できる。
- マージが大変な場合、
おそらく、「変更が局所化できていない」ソースコードだでしょうから、「オブジェクト指向設計」を導入してソースコードをリファクタリングしてください。
- 話は戻りますが、もう一つの利点は、強力な「リビジョン改変機能」です。
