「こわくない Git」というスライドを発表しました
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。
対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！
こわくない Git from Kota Saito
発表中に出た質問など
補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。
- Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？
- A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。この挙動が気持ち悪いという人も多いです。
- A2: 都合上、Fast-Forward の悪い点ばかりフィーチャーしてしまいましたが、ブランチを進めるだけでマージと同じ結果が得られる、というのはエレガントだと思いますし、コミットグラフを持つ「git らしい」と思います。
- A3: ベストプラクティスとしては「--no-ff」を付けた方が運用はしやすくなる、という感じですが、状況やチームポリシーに応じて柔軟に！
- Q: Non Fast-Forward でのマージコミットは勝手にコミットされるの？
- A1: はい。git merge --no-ff topic を実行すると、勝手にマージコミットが作られて、そのコミットメッセージの入力画面に移ります。（-m でコミットメッセージを引数で指定すると、コミットメッセージの入力も省略されてコミットまで自動で行われます）
- A2: ただし、マージ中にコンフリクトした場合は、コンフリクトを解消して git add してから、自分で git commit する必要があります。
- Q: git merge --squash は？
- A1: すみませんハショりました＞＜ 例えば git merge --squash topic は、topic ブランチ上のコミットを1つにまとめて (squash して)、1つのコミットとしてマージする事ができます。
- A2: Git には派閥がいろいろあって、merge --squash 派も一大派閥です。メリットとして、topic ブランチ側の変更が1つのコミットにまとまって見やすいし、取り消しやすい。マージ後の master のログが squash なマージコミットだけになって読みやすい、などがあります。
- Q: で、結局 merge なの？ rebase なの？
- A: 残念ながら一概にどちらがベストとは言えません＞＜ ただ、書いた通り rebase じゃなくて merge で済む場面がほとんどです。最後のまとめページ (P180) に書いた通り、明確な意図/目的を持って rebase するのは全然アリだと思います。
スライドの作り方について
ありがたいことに、色々な方に「どう作ったの？」「フォントは何？」と聞かれるので書いておきます。
まず、バイブルとして、 @riywo さんの下記のエントリを参考にさせて頂きました。ありがとうございます！
かっこいいスライドの作り方 #yapcasia 2012編 - As a Futurist...
使ってるのは Keynote です。
フォント
怖くない雰囲気をだしたかったので、まずは、ゆるふわな日本語フォントを探しました。
英語の git コマンドがたくさん出てくるので、英語フォントも吟味。Google Web Fonts で探しました。
- Bree Serif
- タイトルやちょっと目立たせたいところに使わせていただきました。
- Sansita One
- Question, Point など統一感が必要なタイトルに使わせていただきました。
- Strait
- git のコマンドをクールに見せたいところに使わせていただきました。
無意味に文字を大きくすると、なぜかカッコよく見えますｗ
ただし、テンポが重要なコミットグラフの変形などでは、あんまりコロコロとフォントサイズを変えないようにしています。
色
COLOURlovers で探しつつ、細かい部分については自分で微調整しました。
意識したのは
- 場面が切り替わるところではベース色も変える
- 警告や危ないところには赤系を使う
- 同じものには同じ色を使う (master, topic のブランチとコミットなど)
- コミットグラフが登場するような意識集中が必要なページは暗色系をメインに
- ただし、マンネリが続かないように、適度に刺激 (明るい色) を入れる
あとは、ポチポチと色を選んでいく、という感じです。
図
コミットグラフは、地道に Keynote の図形で丸や矢印をポチポチと置いていきました＞＜
Keynote では、オブジェクトの整列が自然にできるようになってるのが便利でした。（Illustrator などのように、オブジェクトを移動していると中心軸などで吸着する）
図を作る上で心がけたのは
- 同じものには同じ形を使う
- 色と同じで、コミットなら丸、パッチなら四角、という風に形を統一しています。
- 情報量が増えるので、細かい説明を書かなくても伝わる、というメリットがあります。
- コミットグラフの変形や、重要な流れについては、なるべく丁寧に1ステップずつ作る
- おかげでページ数は増えてしまいましたが、「ここがこうだから」→「こうなる」という流れを切らないようにしました。
途中で登場する「犬」や「Git のロゴ」以外に、特に画像は使ってません。
説明・内容
説明を作るにあたって、気をつけていたのは以下のようなことです。
- なるべく、聴衆が考える事を予想して先回り先回りしていく
- 例えば、Fast-Forward でのブランチの移動など、聴衆が予想していない変化には「!?」とキャプションを入れて、「あなたの驚きは間違っていないよ」というのを伝えます。
- 予想するのは難しいですが、効果は高いと思います。
- 時々、主観を変えてみる
- 例えば、犬のキャラクタを入れて「なんだっけ？」「こうじゃないの？」と、聴衆の声を代理してみたり、Git 初心者のよくある勘違いを入れてみたり。
- 主観が変わると、場面転換を兼ねる事ができます。
- ほかにも、マージ中に「Git の中の人」などの擬人化人格を出して、「Git はこう考えている」というのがざっくりわかるようにするなど、説明の補助にも使えます。
- 少し笑いを入れてみる
- 社内向けの軽いノリの場という事もあり、結構ネタが入ってます。
- あまりやりすぎるとクドくなるのですが、それだけ力があるという事でもあり、印象に残りやすいと思います。
とはいえ
いろいろ書いてみたものの、別に上のことを計算して作ったわけではなくて、「わかりやすく伝える」事を目的にしたら、無意識に自分の中でルールが形成されていった感じです。
参考になれば幸いです＞＜
