Git運用のコツについて発表してきた&発表時の補足 #Naite

先週の日曜日(4/24)にGitの運用について発表しました。

  • 告知ページ

nagasaki-it-engineers.connpass.com

  • 発表スライド

speakerdeck.com

はじめに ~この発表を行うきっかけ~

なぜGit運用という発表を行うことにしたか。

それはJJUGナイトセミナーの『Git入門』という回に行ってきたことがきっかけでした。

そこでは、よこなさんが分かりやすいGitの使い方を発表し、しょぼちむさんがGitを運用していくための方法を発表していました。

その時の参加記事はこれ↓

nihonbuson.hatenadiary.jp

これに参加した時に以下のようなことを思いました。

  • そもそものフローを知る機会(発表資料)ってなかなか無いのでは?
  • 運用をどうしてもマンパワーで頑張る感があったので、それをシステム的に何とかしたい!

ということで、これらについて今回発表しました。

特に、GitHubフロー及びGitフローについては時系列できちんとお伝えできたのでは?と感じてます。

スライドの補足

とはいえ、発表では、スライドに載せていないような補足説明が多かったので、それをお伝えしていきます。

5ページ

f:id:nihonbuson:20160502135511p:plain

Gitのコマンド的な話は、今回の発表内容の本筋とは違うので、全てよこなさんのスライドを参考にしてもらうことにしました。

12ページ

f:id:nihonbuson:20160506124737p:plain

当日、質問もあったところですが、ここで主張しているSVNとGitの違いはどちらかと言うとローカル上の話です。

例えば、Jenkinsで対象のブランチを変更したい場合、SVNもGitもどちらともcheckoutを行うと思います。

ただしその際に、SVNでは新たにソースを取りに行く必要があります。

一方Gitは切り替えだけで済みます。

(ここで「リポジトリの複製」という表現を使ったのは完全に間違いでしたね…)

24ページ

f:id:nihonbuson:20160502135529p:plain

ここでの(今回のスライドでの)点線は、リモート上からローカル上にpullしたりpushしたりする部分を表しています。 本当はmasterだって一緒に持ってくるだろうし、正確な図ではないことは百も承知ですが、ここではこのような表記にしています。

28ページ

f:id:nihonbuson:20160502135557p:plain

この図は、「あくまでもローカルとやり取りして、ソースの修正とかが入ってくるのはそれぞれのtopicブランチであり、masterには直接入ることが無いよ」ということを示したかったんです。

43ページ

f:id:nihonbuson:20160502135615p:plain

休憩として、小学校の時に使ったであろう筆洗バケツの話をしました。

ただ、当日の参加者は意外と使っていない(覚えていない)ようで、ピンときてもらえませんでした…。

これは「洗い水やすすぎ水という部分があるから、水を含ませるために使う付け水は、汚れの殆ど無い状態になるよ」と言いたかったんです。

後ほどのスライドに出てくる「topicブランチからのプルリクエストなどの仕組みによって、masterが綺麗な状態に保たれてすぐに適用可能なものになっている」と結びつけるつもりでした。

46ページ

f:id:nihonbuson:20160502135645p:plain

SVNなどのプルリクエストという仕組みが無いところでは、きっとWinMergeやレビューボードを使って頑張っているのだろうなと思っています。

ただし、それらはローカル上で他の人に確認してもらうか、trunk(Gitでいうmaster)にコミットされた後にレビューしてもらうので、非常にコードの状態がよろしくないと思っています。

49ページ

f:id:nihonbuson:20160502135705p:plain

このチケット駆動開発のブランチでの仕組みというのは、以下のようなメリットが生まれます。

  • 本当にその案件の部分しか変更しないようになる
  • 案件に基づいた部分のレビューがしやすい
  • 案件を次サイクルに持ち越した場合に、SVNの時に発生していたような切り戻し作業を行わなくて済む

62ページ

f:id:nihonbuson:20160502135728p:plain

上記でも書いた、チケット駆動開発を確実に行うために、チケット番号が入ったブランチ名にしているかをhookで掴んでチェックするような仕組みを取り入れるべきでしょう。

そうしないと、「ブランチ名をチケット番号にして!」というアナウンスを新しい人が来たり、間違いが発生する度に伝えることになり、教育コストが高くなります。

参考文献

  • slideshareならリンクが貼れて、直接スライドから該当ページに飛べるのですが、speakerdeckではその機能が無いようなので、ここでもリンクを貼っておきます。
    • 本当はslideshareにしたかったけど、フォントの問題でスライドがそのまま反映されないみたいなので、なくなくspeakerdeckへ( ;∀;)

Git-scm

https://git-scm.com

A successful Git branching model

nvie.com

GitHub Flow 図解

qiita.com

git-flow cheatsheet

git-flow cheatsheet

Gitはじめの一歩

www.slideshare.net

一休.comにおけるデプロイフローと自動化

speakerdeck.com

水彩絵の具の使い方

educe-web.craypas.co.jp

"Luca, フォース(force)を使え" - Jenkins開発者が1ヶ月分のGitHubコミットを消失

www.infoq.com

さいごに ~反省内容~

発表時間を余らせてしまったのは反省…。というか、発表終了の時間を間違えてました。

あと、上記でも書きましたが、12ページの「リポジトリの複製」という記載は誤解を招く記述でした。

まあ、あとは概ね発表で伝えたかった内容をほとんど伝えられたので良かったです。