こんにちは。
転職をし、コードを書く側よりコードを管理する側に移行しつつあります。
前職ではコードを書いてその機能テストを行うという開発側の作業がメインでした。
ちょこっと立場が変わり、作業効率の向上や、リリースする際の手間を減らすことも考えなくてはならなくなりました。
現在の職場では、バージョン管理にSubversionを使用しています。
未だに利用している現場は多いと聞きますが、GoogleTrends先生に聞いてみましょう。
Git, bazaar以外は完全に風前の灯火ですね。
bazaarが思ったより強かったのですが、話が飛びそうなので今回は割愛します。
(bazaarについてはこちらを参照してください)
bazaarは分散型でありながらSVNの良さを持っていて、あとはWindowsと日本語でのサポートが手厚いみたいですね。
世の中の技術革新は日進月歩、長いものには巻かれておくべきだと思います。
このTrendグラフを見ただけでもGitへ移行すべきだと思いますが、実利がないとなかなか移行できないと思うので私なりに口説き文句を考えてみようと思います。
Contents
私の経験
Subversion (SVN)
- TortoiseSVNを使用
- 前職では入社して半年あたりでSubversionのインストール
- 勉強のためのソースを読むのにエクスポートやチェックアウトを何度か使用
- 変更管理を手元で行うのが大変であったため、一時的に個人用のリポジトリを作成し、そこでソース管理
- つまりSubversionでの面倒なマージは経験なし
Git
- TortoiseGitとSourcetreeを使用(メインはSourcetree)
- 転職2ヶ月くらい前から使用することを強要される(40↑の方がGitは怖いと使用を拒否)
- Gitでの作業は、主に新機能開発
- Redmineのチケットに対応したFeatureブランチを作成し実装、Masterにマージするまでの作業を担当
- Masterに追加した機能を、別のMasterにマージする作業は熟練者が担当
- Conflict解消のため、slnファイルをテキストエディタで開いて編集した経験あり
こんなところでしょうか。
インストールしてからの日数はSVNのほうが明らかに長いですが、作業密度はGitのほうが濃いです。
そんな私ですが、教わった環境のバイアス込みでGitの方が楽だったなと思います。
私の上司がGitを推進したいが、推進する時間がないと(なんとなくGitのほうがよさそうという勘)のことで特攻隊としてGitを推していこうと考えた次第です。
口説く対象
- 規模 : 管理者、開発者合わせて30～40名
- 平均年齢 : 30代半ばくらい
主に管理側(開発も兼ねる)の10名ほどを口説く必要があります。
Gitを使用したことがある方もいる(私の強い味方)が、基本的にはSVNの経験のみという方がほとんどです。
私の強い味方である先輩も「まぁ、マージ作業の大変さはSVNとそんなに変わらない」という姿勢であるため、ここも納得させる必要があります。
具体的には「Gitはダメな部分もあるよ！けど、SVNで煩雑だった作業がもっと楽になるよ！？」という理論で推していこうと思います。
Gitの悪いところ
学習コストがかかる
よく言われる部分がここですよね。
単純に覚える用語が多いです。
理由は単純で、SVNは扱うリポジトリが1つなのに対し、Gitはリモートとローカルの2つのリポジトリを扱う必要があります。
そして、作業⇔ローカル、ローカル⇔リモートでのやり取りそれぞれに名前がついています。
SVNだと
- チェックアウト(作業環境を持ってくる)
- アップデート(作業環境を最新のものにする)
- コミット(手元の変更を更新する)
- マージ(コミットを他の更新とぶつからないように調整する)
くらいですが、Gitだと
- リモート(SVNのリポジトリと呼ばれるもの)
- ローカル(リモートを作業のためにコピーしたもの)
- クローン(リモートをコピーする作業)
- ブランチ(作業用するためのデータセットを作る、または作ったものをさす)
- コミット(作業をローカルにセーブ)
- マージ(ブランチの内容を他のブランチに統合する)
- プッシュ(ローカルの変更をリモートに反映)
- フェッチ(リモートの更新をローカルに持ってくる)
- プル(フェッチをローカルにマージする)
その他にもリベース(ブランチの形跡を消すマージ)も存在します。
Gitはできないことがないくらいコマンドが豊富らしいです。
何が何をする行為かわからないと、スタート地点にすら立てません。
間違えてプッシュでもした日には、大変なことになります。
こんなサイトがあるくらい、Gitrouble(ギットラブル)が発生しやすいです。
熟練者が必要
導入にあたり、Gitはある程度知見がある方がいるほうが楽だろうなとは思います。
ゼロベースで手探りで始めても良いかもしれませんが、時間がかかると思います。
上記の通り、作業にある程度の知識がないと出荷用のソフト1つ出すだけでも何が起きているか想像できません。
SVNに比べるとトラブルも多いため、いざというときに対応できる方がいないと大変なことになります。
Gitは比較的自由に何でもできるので、管理できる方は必須です。
Gitの悪い部分はこれくらいでしょうか特にGitroubleの頻発がGitにおいての一番の問題点であり、この問題さえ解決できればメリットしかありません。
メリットについても考えてみます。
Gitの良いところ
ブランチが簡単に切れ、作業漏れが少ない
Gitでは作業ブランチを手軽に切れます。
SVNであれば、必要に応じて時間をかけてブランチをいちいち作成する必要がありました。
手軽に切れるので、とりあえず作業ができたタイミングでブランチを切っておけば作業を忘れることはないです。
作業が完了した時点でマージ(またはリベース)を行うことで、追加漏れを防げます。
もっというと、自分が持っているタスクの数=ブランチの数なので、自分の作業に注力できます。
前職では任された作業に対してブランチを切って、切り替えて作業を行っていたので非常に楽にバージョン管理ができました。
ローカルコミットで自分バージョン管理ができる
SVNでのコミットといえば、リポジトリへの更新作業でした。
Gitだと、自分のローカルにのみの一時保存(私はセーブ機能と呼んでいる)なので、気軽にコミットして状態を保存できます。
SVNだと毎回コミットログをきっちり残して、無駄にコミットしないほうが美しくなりますが、Gitであれば適当にセーブしても、リモートにプッシュするときにはいくらでも整形できます。
自分の作業が好きな時に復元でき、それでいて本流を汚さない。
これは管理という観点においては非常に重要な要素だと考えます。
自分環境での作業は個人のルールに任せることができるのは、特に開発者にとっては大きなメリットであると思います。
ブランチ間のマージが簡単にできる
例えばある作業者のブランチに、別の作業者のブランチの機能を取り入れたいとします。
この場合、Subversionであれば
- 必要なソースをファイルとして受け渡す(サーバーが必要)
- リポジトリに必要な機能が追加されるまで待つ
等の手間がかかります。
Gitであれば
- 別の作業者のブランチをリモートに載せる
- 必要な機能追加までをリモートにプッシュしてもらい、必要な人がプルする
とGitだけで完結しますし、無駄な時間ができにくいと考えます。
特に機能追加を待ってから開発を進めるとなると、時間的に無駄ができてしまうことは明らかです。
大きく分けて私が感じたことはこの辺でしょうか。
他にもstashという機能があり、コミットせずとも変更を保持しておくような機能もあります。
私はあまり使ったことありませんが、すごく微妙な変更途中で
「緊急度の高い作業が入ったためチェックアウトしたい！けどコミットして変更したくない！」
というときに有効です。
とはいえ以下のようなブログもあるくらいなので、Gitのメリットだけではどうにも納得できない部分は多いですね。
次回はこのような不満をどのようにつぶしていくか考えてみようと思います。
これがSVNとの差別化を図る上では一番重要だと考えます。
一旦ここで切ります。
コメント