ブログで補足してます： http://developer.cybozu.co.jp/tech/?p=919 cybozu.com インフラ開発・運用チームのソースコード管理システムを Subversion & Fisheye + Crucible から Git & GitHub & kintone に変えるまでのお話です。

1. Git & GitHub & kintone で
ウルトラハッピー！
サイボウズ株式会社 山本泰宇
@ymmt2005
© 2012 Cybozu. All rights reserved.

2. どんな人にうれしい話？
ブランチ管理が地獄のよう • Git なら素早く解決！
だと悩んでいる人 • ブランチ & マージは日常作業になります
Fisheye® + Crucible®
• GitHub は速いしメンテナンスも楽々
に悩んでいる人
Git やってみたいけど、きっ
• Hazama のノウハウ集、共有します！
かけがつかめない人
※Fisheye, Atlassian Crucible は Atlassian の商標です
※Hazama は cybozu.com のインフラツール開発チームです

3. cybozu.com 運用管理ツール
• ストレージ管理
データセンター用 • VM管理
• 各種モニタリング
• 深刻な問題が発生すれば即改修が必要
頻繁なリリース • 依存関係の都合でリリース期日指定も良くある
• 開発環境（試験用）
環境が二つ • 運用環境（試験済み）

4. 開発の流れ
開発DCでQA試験
•設計レビュー •試験済み、かつ
•実装レビュー＆修正 •開発環境用に結合 •リリース可のコードを適用
•バグが混じり、不安定 •週に何回も適用することも
•検出不具合を追加修正
各自開発 運用DCに適用

5. Subversion時代: 不幸のどん底
• trunk に直接コミット
• ブランチ作成は遅すぎて滅多にしない
(作った後のチェックアウトが遅い)
• 安定版を作るには
1. ブランチを作成
2. 未試験のコミットをリバースマージ
• 問題点
• コミットログの精査が人力
• 後回しにすると、ますます辛い
• 安定版ブランチを持つ？
• 目でログを探す点は変わらない
• マージしていないコミットの管理が辛い

6. 解決したい問題
ブランチ作成の高速化 • 個々のタスクごとにブランチを作成したい（トピックブランチ）
• 一度マージした後、追加の改修を再度マージ
マージを繰り返したい • 親ブランチの変更を取り込み後、親ブランチに再度マージ
• まだマージしていないコミットを自動検出したい
マージを楽にしたい • 特定のコミットをすばやくマージしたい
Subversion が遅い • 日々のストレスにもう耐えられません

7. Gitで解決！ その理由
手元にレポジトリ • ブランチ作成やマージはすべてローカル操作
が丸ごとある • だから高速！
リモートレポジトリ • 日々の作業は極めて高速
とは差分更新 • 初回のクローンだけ遅い
コミット履歴は • Git のブランチ＝分岐したグラフの枝
グラフ管理 • Git のマージ＝二つの枝の合流

8. Git vs. Mercurial
Git のほうが強力で、速くて、省スペースで、難しい
• 慣れれば Git の利点が大きい
GitHub が便利すぎる
• これから解説します 
Linux カーネルとその周辺が Git 管理
• Hazama は良く Linux の不具合追うので…
というのは私だけの意見じゃないですよ！
• Why did Git get so much hype? …while others don't?
• Git, Mercurial and Bazaar – A Comparison

9. GitHub Enterprise
Git だけでサイボウズの開発はまわらない
• コードレビューどうする？
• レポジトリ管理・アクセスコントロールは？
• 共有レポジトリは誰が管理するの？
そこで GitHub Enterprise
• github.com を仮想アプライアンスで社内運用
• １ユーザー年間２万円くらい

10. GitHub いいよ！
• GitHub = Gitレポジトリ管理 + レビューツール
• ユーザーが自由にレポジトリを作れる！
• Fisheye® + Atlassian Crucible® より速い
• Fisheye® + Atlassian Crucible® より落ちない
• Fisheye® + Atlassian Crucible® よりメンテナンスが楽
• おまけに Wiki と Gist もついてくる
• Wiki 便利
• Gitレポジトリになっているので、テキストエディタで編集が可能
• 編集がコンフリクトしてもうまくマージできるよ 
• Issues はしょぼい
• kintone と連携すれば最強
※kintone は cybozu.com のアプリ作成ツール
Hazama の開発タスク管理にも使っています

11. PULLリクエスト駆動開発
• PULLリクエスト
• レビュー＆マージツール
• よそのプロジェクトにパッチ投げることもできる
• レビュー OK ならボタン一発でブランチをマージ
• 死ぬほど便利なので、PULLリクエスト中心にワークフローは考えよう！
• ワークフローの例 ここが肝
1. タスクごとにトピックブランチを作る
2. PULLリクエストを投げてレビューしてもらう
3. 指摘事項を修正してトピックブランチにPUSH
4. PULLリクエストの中身が更新されるので、再レビュー
5. レビューOKならレビュワーがボタンクリックでマージ＆クローズ！

12. 導入後のワークフロー
PULLリクエスト 開発レポジトリ PULLリクエスト 安定レポジトリ
トピックブランチ
hazama/infra forest/infra
開発DCでQA試験
•設計レビュー •試験済み、かつ
•実装レビュー＆修正ｗ •開発環境用に結合 •リリース可のコードを適用
•バグが混じり、不安定 •週に何回も適用することも
•検出不具合を追加修正
各自開発 運用DCに適用

13. 言うは易しだが・・・
• hazama/infra は Hazama 開発チーム管理
管理権限を分離 • forest/infra は運用チーム管理
二つのレポジトリを • 試験が終わるまでは hazama/infra にマージ
意識する必要あり • 試験終了後は forest/infra にマージ
開発完了の順に • リリースするべきものだけを chrry-pick
• うまくやらないと、意図しない hazama のコミットが紛れ込む
試験完了はしない • トピックブランチから必要なコミットを自動的に抜き出したい

14. 行うは難し
$ git clone github:hazama/infra
管理権限を分離 $ git remote add stable github:forest/infra
$ git fetch stable
二つのレポジトリを $ git fetch origin
$ git checkout –b INFRA-xx origin/master
意識する必要あり $ git push origin INFRA-xx
$ git fetch stable
開発完了の順に $ git checkout –b INFRA-xx-forest stable/master
$ git fetch origin
$ BRANCH_ORIG=$(複雑なコマンド)
試験完了はしない $ git cherry-pick --first-parent --no-merges $BRANCH_ORIG..origin/INFRA-xx
$ (コンフリクト修正)
$ git push origin INFRA-xx-forest

15. hazama tools でウルトラハッピー！
git-hazama 拡張コマンド
kintone API クライアント
github v3 API クライアント
github-kintone 連携 Chrome 拡張
GitHub で公開してます！
https://github.com/ymmt2005/hazama-tools

16. git hazama でこうなる！
$ git hazama setup infra
管理権限を分離 (clone して remote 追加)
$ git hazama dev
二つのレポジトリを ….
$ git hazama review dev TICKET
意識する必要あり (トピックブランチ作成, PUSH, PULLリク作成, kintone 更新)
$ git hazama pick TICKET
開発完了の順に (必要なコミットを自動 cherry-pick)
$ git hazama stage TICKET
試験完了はしない (forest/infra へのPULLリク作成, kintone 更新)

17. GitHub ⇔ kintone 連携
← Chrome 拡張でチケットに自動リンク
↑ git hazama が PULL リク自動記載

18. Git に乗り換えるには？
Hazama謹製 • 要望あれば公開検討します！
チュートリアル • @ymmt2005 までどうぞ
• git svn のラッパー
svn2git
• 関連の薄いモジュールのレポジトリは分割インポートがお勧め
GitHub アカウント • サインアップしてご自由にどうぞ
• 「コミットグラフ」の意味がわかるくらいでないと厳しい
一人は慣れていること
• 各チーム一人は、隠れ Git ユーザーがいるでしょう 

19. Good Luck!