セミナー情報
- 名称 : Getting Git Right 〜 きっとできる Git
- 日時 : 2014/09/26(金) 16:00開始
- 場所
- 会場 : ベルサール八重洲 room 2 + 3
- 住所 : 東京都中央区八重洲1-3-7八重洲ファーストフィナンシャルビル3F
- ハッシュタグ : #gettinggitright
- まとめ : Getting Git Right きっとできる Git まとめ - Togetterまとめ
セミナープログラム
| 時刻 | アジェンダ | タイトル | Speaker | 資料 | 動画 |
|---|---|---|---|---|---|
| 15:30 | 開場 | ||||
| 16:00 | 挨拶 | Stuart Harringtonさん(アトラシアン 日本法人代表取締役社長) | |||
| 大貫 浩さん(リックソフト) | |||||
| 16:10 | 講演 | Be a Happier Developer with git | Tim Pettersenさん(Developer Advocate, Atlassian) | 参考 : Getting Git Right | Be a Happier Developer with Git and Productive Teams #gettinggitright - YouTube |
| 講演 | Productive teams | Abhin Chhabraさん(Bitbucket Developer, Atlassian) | 参考 : Getting Git Right | Be a Happier Developer with Git and Productive Teams #gettinggitright - YouTube | |
| 17:55 | デモとまとめ | 長沢 智治さん(アトラシアン株式会社テクニカル エバンジェリスト) | Getting Git Right 〜 きっとできる Git 〜 世界ツアー東京開催の資料と動画 #GettingGitRight | Getting Git Right 〜 きっとできる Git 〜 世界ツアー東京開催の資料と動画 #GettingGitRight | |
| 18:30 | 懇親会 | ||||
| 資料に挙げたGetting Git Rightは、2014年6月までに講演された内容であり、本公演での内容とは細部が異なります。 |
内容
挨拶
Stuart Harringtonさん
- 1スライド、1笑いを要求され、こなしていた
- 会社がマリノスタウンにある
- アトラシアンの前は、イタリアレストランが入っていた
- イタリア料理店やマリノスショップと間違えられる事がしばしば...
- シェフが会社にいる開発会社
- でもって、ピザ食って、うまー
大貫 浩さん
- リックソフトは、アトラシアン製品の販売とプロフェッショナルサービスをおこなっている会社
- FY14(2014会計年度)において、日本での売上第1位エキスパートになった
- 販売の為のパンフレットは、Atlassianエキスパートの会社(リックソフト)が作っている
- Atlassian製品の販売だけでなく、アドオンも作り、販売している(WBSガントチャート for JIRA)
- クラウドサービスもおこなっている(リッククラウド)
講演
Abhin Chhabraさん
Gitの優位性に関する話
- Speed, speed, Speed
- Everything is local
- localというのは、pushとpullを除く
- Written in C by Linux kernel and filesystem developers
- Linus Benedict Torvalds : ワイがLinuxとGitを作った
- (最初のCloneを除き、)svnと比べて、Gitは速い
- なぜ、リポジトリが大きくなるの?
- Freedom & Safety
- Feature Branching
- やる事
- 何か(バグ修正、機能追加、typoなど)あったら、まずブランチを切れ
- そして、切られたブランチでの開発が完了したら、Mainブランチ(trunk)にマージしろ
- コマンド
- ローカル : git checkout -b new-branch
- サーバー : git push origin new-branch
- やる事
- git stashはスゴイ
- コマンドの意味
- 今の作業内容を一時的に保存するコマンド
- 例えば、ボスが「バグ修正版のリリース早よ!」と叫びながら、あなたの席に来たら...
- Gitでは、慌てる事は無い。あなたは、git stashを実行し、Mainブランチに切り替えして、バグを修正し、マージし、push、デプロイ。終わったら、途中の作業をリストアする。
- svnでは、こうはいかないよね
- コマンドの意味
- Safety
- もし、サーバーがクラッシュしたら、どうする?
- 問題ない。Gitは、全てのクライアントに全てのデータ(clone)がある。それを復元するだけだ。
- Gitには、ファイルを復帰させるコマンドもいろいろある
- 詳しくは、Titanium Armor: Recovering From Various Disasters | Atlassian Git Tutorialを参照
- もし、サーバーがクラッシュしたら、どうする?
- Explore & Understand
- Gitは、ログからいろいろな事が分かる
- 誰が、いつ、何を変更したのか
- 誰がファイルを消したのか
- grepすれば、定数が何処で宣言されているのかも分かる
- mergeしたかどうかも分かる
- Control & Assemble
- mergeとは、「featureブランチの変更をmasterブランチに適用する」事
- Gitのmergeが優れている所 : 速く、優れている
- mergeはlocalでおこなう
- Gitは親のリビジョンを遡る事で過去を遡る事が出来るが、SVNは全てのリビジョンを保持している為に遅い
- mergeが賢い
- mergeはイベントじゃなくなるよ
- rebase
- コミットを1対1でリプレイする事。masterブランチの最後に、featureブランチの全てのコミットを繋げる
- 注意 : rebaseはコミットログ(歴史)を書き換えるので、気を付けて使う事
Tim Pettersenさん
- Efficient Workflows
- 一番良いGitを使ったワークフローとは?
- 異なる文化、製品、チーム。それぞれに異なったワークフローがある
- 自分たちのチームに合ったワークフローを作ろう
- アトラシアンでのワークフローは
- Issueごとにブランチを切る
- ブランチは完了するまでmasterブランチから切り離し、テストが完了したらmasterブランチへマージする
- ブランチはtypoでも、機能追加でも、バグ修正でも、何でも切る
- ブランチの例
- JIRAの30番のissueでユーザーのアバター関するFeatureブランチ : feature/JIRA-30-user-avatars
- JIRAの31番のissueで認証に関するbugfixブランチ : bugfix/JIRA-31-3lo-NPE
- JIRAの32番のissueでIE8に関するhotfixブランチ : hotfix/JIRA-32-broke-ie8-again
- JIRAは、切るブランチの名前をある程度自動で決めてくれ、ブランチを切る前に、ビルドが成功しているかを確認する事が出来る
- Issueごとにブランチを切る
-
Automatic merges
- with a Git hook
- with Stash
- 一番良いGitを使ったワークフローとは?
- Improving Code Quality
- コードレビューの良い所
- コードをより良く出来る
- 知識を共有できる
- コードをチームで共同所有する
- レビューをおこなう事で、何かあった時の開発者の罪悪感が薄れる
- コードレビューは、GitではPull Requestsを通しておこなう
- Stashにはコードレビューを助けてくれる機能をがある
- コードレビューの良い所
- Git and Yout Toolchain
- Issueがどんな状態かは、Stashですぐ分かる
- 何が行われているかはHipChatでやり取りされると、メールを辿る必要が無い。
- 何故、Gitを使うか?
- それは、経済的だから
- ソフトウェア開発が速くなり、バグが少なくなり、顧客が喜ぶから
- 速く、賢くソフトウェアをリリースする
- それは、経済的だから
質疑応答
2人目
Q. ゲーム会社で、現在はPERFORCEを使っている。開発者はGitを使いたいけど、アーティストは「Git分かんない、無理」という状況。どうしてもローカルに全てのファイルを置けないという事情もある。何か良い案やソリューションはありませんか?
A. git-mediaを使いましょう。(参考 : もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術)
デモとまとめ
長沢 智治さん
- デモシナリオ
-
- Confluenceで企画を立てる
-
- JIRAで計画を立てる
-
- Bambooでビルドし、デプロイする
-
- デモ
- JIRA, Bambooは、何が変わったかを全て知っている。変更により何が追加されるか、以前のバージョンに戻す事で何が失われるかもすぐ分かる
- 開発が正しく(嘘なく)進められる。ずっと変わらない進捗85%とかは無くなるね
- それぞれの関係者(開発、企画など)が必要な所にフォーカスしやすくなる
- Gitだけだと、分散しやすくなるので、JIRAを中心としたワークフローを作るのが良い
感想
- 「サーバーが死んでも、ブランチを全部消しても戻せる」→「死んだと言ったな。あれは嘘だ」というセリフが頭をよぎった
- Gitは、SVNよりもかなり優れているんだな
- 「Gitが優れているから使う」のではなく、「自分たちの製品を出す為に、最適なワークフローをまず考え、その上でGitをベースとした開発をおこなう」事を選ぶ方が賢い。
- ワークフローを作る/変更するなら、それを良い機会と考え、企画/計画/開発/テスト/リリースをどのようにおこなうか、どのようなツールを使うかを考えると良いと思う
- 基本的なワークフローについては、このセミナーで触れられていたので、ある程度の期間、部分的に取り入れてみて、自分たちに合うかどうかを振り返ってみると良いと思う