SCM Boot Camp

SCM Boot Camp

bleis-tift

July 30, 2011

自己紹介

id:bleis-tift / @bleis

名古屋から来ました

F#プログラマです

お仕事でGit使ってます

お仕事以外でもGit使ってます

自己紹介

Git-HooksっていうGitのフックスクリプト書いてます。

https://github.com/bleis-tift/Git-Hooks

rewriteブランチで時期バージョン開発 (停滞)中

利用者の声そのいち

利用者の声そのに

名古屋Reject会議にて、の発表

利用者の声そのさん

Geek Barにて、

「え、まだ名前 (bleis hookに)変えてなかったんですか？」

・・・

rewriteブランチが固まったら名前変えます・・・

話すこと

バージョン管理

バージョン管理システムの分類

分散バージョン管理システム

SVNとの比較

運用例

事例紹介

オープンソース寄りの話ではなく、業務寄りの話になります。Git固有の話とかはしません。ちょっとしか。

バージョン管理

バージョン管理とは

変更の履歴を管理することそれだけではよく分からないので、バージョン管理する目的を考えると・・・

バージョン管理する目的

いつでも過去のバージョンに戻せる

変更に対するメタデータの格納

変更の調査

大体こんな感じ。なので、バージョン管理とは・・・

バージョン管理とは

過去の状態を取り戻すことができ、

変更の意味などを保持し、

変更に対する多様な調査を可能にすること

「過去バージョンに戻せる」が注目されがちでも、それだけじゃない

日付.zipはバージョン管理と呼べるか

過去のバージョンには戻せるけど・・・

変更の意味は保持していない

変更に対する基本的な調査も困難

なので、日付.zipはバージョン管理とは呼べない

履歴コメントはどうか

変更の意味は保持しているけど・・・

過去のバージョンに戻すのが困難

変更に対する基本的な調査も困難

何より可読性が落ち、バージョン管理以前の問題

なので、履歴コメントはバージョン管理とは呼べない

二つとも採用したらどうか

カオス！バージョン管理を行うにはツールの採用が必要不可欠

ツールを使わない言い分

1つの場所に全てが書いてないと不安・・・

バージョン管理システム？何それ・・・

色々できるらしいけど・・・使い方わかりません

ツールがバグってたら・・・

ツールを知れば解決！SCM Boot Campマジ SCM Boot Camp

ツールを知るということ

動作、コマンド

概念、文化、思想

実装

「動作」さえ知っていれば一応使えるでも、使いこなすには「概念」を知る必要がある

「実装」はお好みで・・・

概念

ツールごとに文化や思想が違うので、概念も異なる

例：Git⇔Mercurial

基本的な操作は同じように見えても、細かいところは結構違う

ちょっと横道に逸れて、どういうところが違うのか見てみましょう



メインでGitを使っているので、Gitと他のVCSとの違いを中心に

ファイル名の管理方法

ファイル内容の管理方法

協調方法

集中管理 or 分散


例えば、ファイル名の変更や移動をどう扱うか。管理しない

本当に何もしない (CVS)ヒューリスティックに解決 (Git)

専用コマンドを用意 (SVN/HG/BZR)


ヒューリスティックに判断する方法の利点は、通常のファイル操作コマンドが使える点。欠点は、確実ではない点。専用コマンドを用意する方法の利点は、変更のメタデータとして記録するので、確実な点。欠点は、通常のファイル操作コマンドが使えなくなってしまう点。


差分を積み上げて最新の状態を表す (SVNなど)

スナップショットを格納する (Git)




協調方法

ロック (VSS)

マージ (その他)

ロック VS マージ

ロック方式の利点は、コンフリクトが発生しない点・・・本当？ファイル内でのコンフリクトは発生しないけど、ファイル間の見えないコンフリクトは普通に発生する・・・バイナリをいじるのでもない限り、ロック方式に利点はないと思うんだ・・・

集中管理 or 分散

集中管理 (SVN)

分散 (Git/HG)

両方 (BZR)

お待たせしました。ようやく分散バージョン管理システムの話です。

分散バージョン管理システム

DVCSよくある？勘違い

一つのリポジトリが分散している、という誤解

commitのたびにほかのリポジトリに通知が行く、という誤解

一人だからDVCSじゃなくていいや、という誤解

業務では集中管理型じゃないと破たんする、という誤解

一つのリポジトリが分散？

一つのリポジトリが分散？

最初そう思ってた

これは「分散」という言葉がまずい？

実際には「完全なリポジトリ」が複数存在する

commitのたびに同期？

commitのたびに同期？

最初そう思ってた

操作のたびに他の人のリポジトリ弄るとか何それこわい

リポジトリ間の同期は明示的に行う

一人だからDVCSいらない？

むしろ、一人の際に集中管理型を使う利点はない一人で使うとしてもDVCSにはメリットが多い

手軽高速高機能

ここでも「分散」という言葉が・・・

業務では集中管理型？

better集中型としてのDVCS

向き不向きはあるけど、それって他のツールでも同じこと

中央にSVNを置き、個人でDVCSというのも可能

例えば、日本語ファイル名を使いまくっているところにGitを導入するのは難しい

バージョン管理する目的 (再掲)

いつでも過去のバージョンに戻せる

変更に対するメタデータの格納

変更の調査

DVCSはこれらの目的のためだけにとどまらない

DVCSでできるようになること

自由なコミット

自由なブランチ

自由な歴史改変

DVCSでは、集中管理型ではできなかったことができるように！

トピックブランチ

DVCSではローカルブランチを気軽に作れる→作業の単位でブランチを作り、作業が終わったらマージ

作業？

hoge機能追加、とか、バグ修正、とかDVCSならこんな小さなレベルでブランチを使っても苦になりません。

コミットの粒度

トピックブランチを使うと、コミットの粒度を細かくできる

いつコミットすればいいの？

保存したということは、何かの区切りの可能性が高い

最初のうちは、保存のタイミングでやったことを顧みる

rebase

枝分かれしてしまった状態これを、どの変更も反映して合流させるには・・・

rebase

枝分かれしてしまった状態これを、どの変更も反映して合流させるには・・・

rebase

rebaseはDVCSならではの方法です。こんな感じ

rebase

rebaseはDVCSならではの方法です。こんな感じ

rebase

トピックブランチ程度の小さなブランチに

大きいブランチだときつい

rebaseの何が嬉しいの？

リポジトリの状態がきれい

歴史の二分探索がカチッとはまる

参考：マージコミットの分割が１本線の履歴の分割よりも困難となる理由http://www8.atwiki.jp/git jp/pub/Documentation.ja/user-

manual.html#bisect-merges

BTS/ITSと使う

トピックブランチを使い、コミットの粒度が細かくなり、ブランチのマージに rebaseを使うようになると・・・

どこからどこまでがどの作業のコミット？

BTS/ITSと一緒に使うのは一つの解決策

SVNとの比較

SVNとの比較

まだまだ現役の SVNと以下の観点で比べてみます。

コマンド

ブランチ

開発スタイル

コマンド

SVNには svnコマンドとは別に、リポジトリ用コマンドがある

ブランチ

SVNではブランチは自分の環境内で閉じないのに対して、DVCSではローカルなブランチが作れるリポジトリの cloneもブランチと考えることも可能

開発スタイル

リポジトリの用意

コミットが失敗する可能性

マージの失敗の取り消し

リモートとのやり取り

リポジトリの用意

SVNの場合・・・サーバにログインして、リポジトリ作って・・・面倒！

DVCSの場合・・・

git init

より気軽にバージョン管理を開始できる！













マージの失敗

マージの失敗

マージの失敗

マージの失敗

マージの失敗

マージの失敗

マージの失敗

マージの失敗

マージの失敗


SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り

















注意点

最小単位であるコミットレベルでリモート通信している SVNと異なり、DVCSではコミットレベルではリモート通信が発生しないので、pushし忘れることも・・・

Gitの場合、http://d.hatena.ne.jp/pasela/20110216/git not pushed

などを参考にどうぞ。

運用例

中央にSVNを使い、個人でDVCSを使う

MercurialやBazaarでも同じようなことができる

中央にSVNを使い、個人でDVCSを使う

他の人に影響を与えずに導入できるコミットフックを使っている場合は要注意

たくさんのコミットを一気に SVN側に投げると・・・SVNのコミットと同程度の大きさに留め、こまめにコミットするか、トピックブランチ一つ分を圧縮して一つのコミットにまとめる

SVNを介して、複数のDVCSを共存させる？

作業ディレクトリに混ぜて使う

ブリッジが用意されていない場合など、最後の手段

中央にもDVCSを使う

中央もDVCSになっていたほうが何かと便利

階層

可能性は無限大！

事例紹介

事例紹介

と言っても、うちの事例ひとつだけですが

Jenkinsとの組み合わせ

うちの会社で運用している構成CIのビルドが失敗するような pushを弾く

.

.

.

1 中央のリポジトリへの pushを禁止

.

.

.

2 サーバ側に開発者ごとの push用リポジトリを用意

.

.

.

3 各 push用リポジトリから中央のリポジトリへのpushは CIが行う



開発者が 5人以下のチームで採用

初めて構築、運用しだして 1年経過

新規案件を中心に、5案件ほど回した

小さいチームではうまくいくことが分かった

大きいチームでは難しいかも・・・？

おわり

Technology

SCM Boot Camp