GitHub実践入門-Pull Requestによる開発の変革- スピード感想
昨日、弊社の社内勉強会にGitHub実践入門の著者である @HIROCASTER さんにお越しいただき、GitHub活用術の話をしていただきました。
さらにひょんな流れから、なんと「GitHub実践入門」の本まで頂いてしまった！
ありがとうございます！！ありがとうございます！！
まだ流し読みしかできていないのですが、スピード感想をここに。
心に残ったフレーズ
- Pull Requestを育てる
- GitHub単体だと、現在利用しているプロジェクト管理ツールよりも機能的に足りない点もあるかと思います。ですが、その足りない機能を一度捨ててみることも検討してください。GitHubのような非常にシンプルな機能だけで、ソフトウェア開発は十分にできるはずです(Issueとかの話)
- 常にデプロイ。リリースという概念はない(GitHub Flowの話)
- すべての変更をステージング環境で確認してからデプロイするのはナンセンスです(GitHub Flowの話2)
下2つはあまりに自分の環境と違いすぎてうおおと。
GitHub Flowは、開発者が主体になってるサービスで、自由に変更をリリース(デプロイ)できる人達が使うものだと確認。。。。
やっぱしばらくgit flowを使っていくことになりそう
ただシンプルがベストっていうのはこの本でも昨日のお話でも強く主張されてたところだった
GitHubが(特に弊社で使用しているStashと比べて)面白いなあと思ったこと
- : って入れると絵文字の補完機能がある。円滑で素敵なコミュニケーションに
- ブランチ絵デフォで見れる
- "fix #24"とかcommitコメントに書くと勝手にIssueをcloseしてくれる(ただこの機能はぶっちゃけいらないｗ)
- Pull Requestでチェックボックスのタスクリストかける
- hubコマンドが長くなりがちなgitのコマンド簡略化してくれて便利
このレビューが終わったら1杯引っ掛けようやって気持ちをここに
やりたいなと思ったこと
- WIP Pull Request (Work In Progress Pull Request)
- [WIP]*** function addition みたいに、Pull Requestの先頭に[WIP]ってつけることで、そのコードがまだ開発中だよってことを表す
- コードが完成してからでなく開発中の時点でPull Requestを送っておく
- そうすることでいきなり大量のソースをレビューになってから見ることはなくなるし、開発中にPull Request上で議論することも出来る
- commit単位を小さく。あ、ついでにここも治そうっていうのがあったら、それはcommitを分ける！
- Pull Requestでレビューする人から見て、このためのにここを直したっていうのがわかりやすくなる
この2点が簡単に取り入れられそうで、効果もありそうなので、周りに広めていきたい
Pull Requestは今でも使ってるものの、「レビューは時間あるときね」「見る時間ないから自分たちでレビューしておいて」みたいなレビューに対する障壁はまだまだ感じているので、薄くなっていくといいなあ
本を通して
ネタバレになっちゃいますが、はじめてのPull Requestの練習ということで、
この本の感想ページがかかれたリポジトリを実際にforkしてきてにPull Request->Webページに反映させるという企画があって、
それがすごいオープンソースな感じで感動した。ほんとGitHubだから出来る@naoya_ito さんもTwitterで言っていましたが、単なるgitとgithub利用方法だけでなく、かなり活用方法に触れてたのが良かった。特に9章の開発フローのところはすごく参考になった
以上、流し読みですがスピード感想でした。
これからもっとじっくり読んで咀嚼していきたいと思います。
P.S.
Ship It Squirrel and the Update the Plan Elephant - Geoffrey Wiseman
結局なんでリスがShip itなのか謎。。。リスのように軽快に開発すべしってことなのでしょうか。
誰か教えてください
