scm boot camp
Post on 19-Jun-2015
14.548 Views
Preview:
DESCRIPTION
TRANSCRIPT
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・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
SVN・・・ほぼ全てがリモートとのやり取りDVCS・・・ほぼ全てがローカルで完結限られたコマンド (cloneや pushや pull)がリモートとやり取り
リモートとのやり取り
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が行う
Jenkinsとの組み合わせ
Jenkinsとの組み合わせ
開発者が 5人以下のチームで採用
初めて構築、運用しだして 1年経過
新規案件を中心に、5案件ほど回した
小さいチームではうまくいくことが分かった
大きいチームでは難しいかも・・・？
おわり
top related