https://blog.yusuiked.dev/categories/vcs/ Recent content in Vcs on yusuiked's blog Hugo -- gohugo.io ja-jp yusuiked@gmail.com (yusuiked) yusuiked@gmail.com (yusuiked) Sun, 19 Dec 2010 16:01:31 +0900 https://blog.yusuiked.dev/posts/2010/12/19/attended-distributed-version-control-study-meeting/ Sun, 19 Dec 2010 16:01:31 +0900 yusuiked@gmail.com (yusuiked) https://blog.yusuiked.dev/posts/2010/12/19/attended-distributed-version-control-study-meeting/ <p>最近，Gitを勉強しようと思っていたらタイミングよく勉強会があったので参加させていただきました。</p> <ul> <li> <p><a href="http://kokucheese.com/event/index/6329/">12月17日 分散バージョン管理勉強会(東京都)</a></p> </li> <li> <p>まとめ</p> <ul> <li><a href="http://sourceforge.jp/projects/shibuya-trac/wiki/meeting/13">meeting/13 - Shibuya.trac Wiki - Shibuya.trac - SourceForge.JP</a></li> </ul> </li> </ul> <p>DVCSについて，外観からディープな話題，ネタ発表までバラエティ豊かな発表でとても楽しかったです。特に，神速さんのゆるふわ愛されキャラ振りはすごいw<br> 以下，各発表のメモ＆感想です。</p> <h4 id="分散バージョン管理システムってなんなんおかもとさん">分散バージョン管理システムってなんなん？（おかもとさん）</h4> <ul> <li> <p>前説ということで，場を暖めるために様々なネタがちりばめられていましたが，会場の照明が思ったよりも明るく，スライドが見えにくくなってしまったためあまりオチなかったところが逆に面白かったw</p> </li> <li> <p>CVS→現在までのバージョン管理ツールの変遷</p> <ul> <li>書籍とかである程度事前知識を入れてはいたけど，改めて聞いておさらいができた</li> </ul> </li> <li> <p>分散バージョン管理のメリットはよく聞くけど，デメリットはあまり知らなかったので勉強になった</p> <ul> <li> <p>特に，ロックができないというのは<a href="https://blog.yusuiked.dev/posts/2010/12/19/attended-distributed-version-control-study-meeting/#f1" title="アーキテクチャをよくよく考えれば当たり前なのだけれど">*1</a>，バイナリファイルの扱いが難しいということで，Excelなどのファイルを管理するのは難しいのかな？</p> <ul> <li>調べたら，MercurialはTortoiseHgを使えば差分が取れるらしいので，Windowsユーザにも優しいようだ</li> <li>この点は，現場導入するにあたってMercurialかBazaarに揺れる一つの要因になりそう。あとGitのコマンドを現場のメンバに覚えさせるのは難しい気もするし。</li> </ul> </li> </ul> </li> <li> <p>Git,Mercurial,Bazaarの比較</p> <ul> <li> <p>比較表はもうちょっとじっくり見たかった</p> <ul> <li>スライド公開された<a href="http://www.slideshare.net/TakashiOkamoto/20101218-6213044">分散バージョン管理システムって何なん 20101218</a></li> </ul> </li> <li> <p>リビジョン表示は，Gitの場合ハッシュだけど，revertする時はコミットログが頼りになるのかな？そうするとメンバーにしっかりコミットログを書かせるようにしないと厳しそう</p> </li> </ul> </li> <li> <p>まとめ</p> <ul> <li>デメリットも考慮して，Subversionから移行しないというのも一つの選択肢，というのは肝に銘じておこうと思った</li> </ul> </li> </ul> <h4 id="gitとhudsonによるきれいなリポジトリの作り方idbleis-tiftさん">GitとHudsonによるきれいなリポジトリの作り方（<a href="http://blog.hatena.ne.jp/bleis-tift/">id:bleis-tift</a>さん）</h4> <ul> <li>テライケメン</li> </ul> <h5 id="前半部ソフトウェア開発に対する思い">前半部（ソフトウェア開発に対する思い）</h5> <ul> <li> <p>ソフトウェア開発で発生する問題としての手動テスト，Excel管理，Excel設計</p> <ul> <li>まずこれらを卒業するのが先決ですよね。汎用機文化の人たちにこれをわからせるためにはどうしたら良いんだろう…<a href="https://blog.yusuiked.dev/posts/2010/12/19/attended-distributed-version-control-study-meeting/#f2" title="彼らの文化全否定ですからね…">*2</a></li> </ul> </li> <li> <p>バージョン管理システムを使っているだけではダメで，正しく使わないとダメ</p> </li> <li> <p>集中管理型は使っているみんなが変更を知っていないとダメ</p> <ul> <li>使っているみんなに間違った影響が伝播してしまうから</li> <li>そもそもバージョン管理ツールの仕組みから知ってもらわないとこういうことってわからないんですよね…どうやって時間を取ってもらうか。彼らはこういう勉強などいっさいしないし…</li> </ul> </li> </ul> <h5 id="後半部きれいなリポジトリ">後半部（きれいなリポジトリ）</h5> <p>分散バージョン管理初心者の私には結構高度なテーマでしたが，説明がわかりやすかったので聞いていて何となく理解はできました。ただ，自分でこの環境を構築しようとするのは今のレベルでは難しいかも。</p> <ul> <li> <p>ここではいつ取ってきてもビルド可能なリポジトリのことをきれいなリポジトリとして定義</p> <ul> <li>自分がミスっても他の人に影響を与えることがない</li> </ul> </li> <li> <p>CIを導入することで，リポジトリが更新されたきっかけでビルドを走らせることによって素早いフィードバックを得ることができる</p> </li> <li> <p>ただし，フィードバックだけでは不足で，汚してもよい領域ときれいな（ビルドが通る）領域とに分けて管理することで，きれいなリポジトリが実現できる</p> </li> <li> <p>ブランチ分割</p> <ul> <li>更新をかける開発者ごとのブランチと，実際に更新されるブランチに分ける</li> </ul> </li> <li> <p>リポジトリ分割</p> <ul> <li>きれいなリポジトリと，開発者が壊しても良いリポジトリに分ける</li> </ul> </li> <li> <p>hookでmasterブランチを直接pushできないようにし，privateブランチの更新をhookしてビルドする</p> </li> <li> <p>利点・欠点</p> <ul> <li> <p>開発者が増えたとき</p> <ul> <li>ブランチ分割の場合，CIのジョブを増やすだけ</li> <li>リポジトリ分割の場合，リポジトリも増やして設定する必要がある</li> </ul> </li> <li> <p>最新ではないもののpush</p> <ul> <li>ブランチ分割の場合，ロールバック？通知だけ？</li> <li>リポジトリ分割の場合，ロールバックするだけ</li> </ul> </li> <li> <p>リポジトリ分割の場合，hookを差し込む場所が多くなる</p> </li> <li> <p>テストの分割</p> <ul> <li>privateリポジトリで単体テスト</li> <li>centralリポジトリにpushされたタイミングでhookして結合テスト</li> <li>このアイデアは言われてみれば合理的だけど，すごいと思う。というか実現したのがすごい</li> </ul> </li> </ul> </li> <li> <p>最初に試すのはブランチ分割がおすすめ</p> <ul> <li>hudsonのgitプラグインのオプションにあるらしい</li> </ul> </li> </ul> <h4 id="traclightningとtortoisehgのゆるふわな連携idwyukawaさん">TracLightningとTortoiseHgのゆるふわな連携(<a href="http://blog.hatena.ne.jp/wyukawa/">id:wyukawa</a>さん）</h4> <p>ゆかわさんの発表はHudson勉強会に続いて２回目の聴講でした。</p> <ul> <li> <p>Mercurialの特徴</p> <ul> <li> <p>コマンドがSubversionに似ている</p> </li> <li> <p>単機能（Gitは多機能）</p> </li> <li> <p>拡張機能が豊富</p> <ul> <li>リベース，歴史改変，チェリーピック，部分コミット，シェルフなど</li> <li>うーむ，勉強不足なのでよくわかってません。勉強します。</li> </ul> </li> <li> <p>Mercurial Queue(MQ)というGitのインデックスに似たパッチ管理機能</p>