Git 移行の冴えたやりかた

たったひとつの※1・・・とタイトルにつけたいところですが、自粛しました。
読む本の大半が SF な山本泰宇です。

Git & GitHub & kintone でウルトラハッピー!」で紹介しましたが、サイボウズでは昨年 Git と GitHub Enterprise を導入し、それまでの Subversion 中心のシステムから移行しています。

開発システムはソースコード管理だけではなく、レビューシステム、ビルドシステム、BTS、ドキュメント、その他さまざまなツールやシステムを組み合わせて構成されます。長年 Subversion や CVS を中心にしてきた組織では、さまざまな仕組みがそれに依存しているので、Git に移行したくてもできない!とお悩みのところも多いのではないかと思います。

ここからが本題。システムの準備は少人数で進められます。前回紹介した Git, GitHub, kintone を組み合わせるシステムは私ともう一名でツールの調査・選定を進めました。でもシステム切り替え時には、関係する全員がスムースに業務を継続することができるようにしなければなりません。

そこで Git を使ったことがない開発者でも日常の開発業務がすぐ行えるように、以下に取り組みました。

  1. 開発業務の流れ(ワークフロー)を決める
  2. ワークフローで必要となる操作をマニュアルに記す
  3. 複雑な操作を要するところは、簡易な操作ですむようにツールを開発する

ツールについては前回の記事で紹介したように、git hazama 拡張コマンドとして GitHub で公開しています

今回はそのときに作成した、ワークフローやマニュアルを公開します。この取組の結果、10名ほどのチーム全員がスムースに新システムに移行できました。また、他のチームもこのマニュアルやツールをコピー&フォークして Git への移行に活用しています。

目次だけ、こちらにも転記しておきます。皆様のご参考になれば幸いです。

* Git とは
** Git の仕組み
** リモートレポジトリ
** チュートリアル
* GitHub 概説
** レポジトリ管理
** コミュニケーション
** PULLリクエスト
** Gist
** Wiki
** Issues
** API
** アーカイブ
* 最初にやること
* 練習
* ワークフロー
** タスク管理の方法
** 開発レビューまでの作業
** 試験で不具合がみつかったときの作業
** `forest/infra` へのマージ
* ベストプラクティス
** Git 編
** GitHub 編
* Tips
※1 ジェイムズ・ティプトリー・ジュニア著「たったひとつの冴えたやりかた」より