来月からGitHubを社内で導入することになりましたという連絡をいくつか受けている@HIROCASTERでございませう。
プログラマが使いたいと思える環境が提供され、ストレスから解放される事を心から期待します。そして、新たな文化へ触れることを嬉しく思います。
WEB+DB PRESS Vol.69の特集とGitHubのイベントによる影響があるようです。(このあたりからも感謝の気持が送られてきたりとか…ありがとうございます。)
やはり、実際に活用されている事例をいくつかの業種を通して比較できたことは有意義だったのかもしれません。
そこで、GitHubを先取りして利用している立場から、GitHubを使い始める際の準備や、考えたり決めておくと良いことをいくつか紹介します。
Git
そもそもGitを基本的に使えるようになっておこう。
濱野 純(Junio C Hamano) |
Gitのメンテナーである濱野さんが書かれた本がオススメ。
お金を出すのが惜しい人は
あたりで、学ぼう。
githugなどで実際に手を動かしながら学習して身につけましょう。
個人的にはGitはコンソールから実行するのが一番シックリ来ています。
.gitconfig
gitの設定を徹底的にきちんとしておくこと。
濱野 純(Junio C Hamano) |
あたりで知識を補完しながら
あたりの実際に使用している人の設定を参考にすると、スタートダッシュできる。
ブランチ戦略
ブランチ戦略をきちんと立てないと、カオスになるので、考えよう。
“A successful Git branching model”の日本語訳があるので、こちらが参考になる。
GitHubを使う上でのポイントは、各ユーザーごとにリポジトリをForkせずに別ブランチをつくっていくことにより開発を進めることをオススメする。各ユーザーごとにForkするとかなり複雑になる。
WEB+DB PRESS編集部 |
の特集の中でも、Forkついては触れている。
Gitの基本操作とブランチ戦略を含め、簡単にワークショップを開催すると良い。
コミットログ
コミットログをどのように書くか、きちんと決めていないのであれば、見直そう。
Gitスタイルあたりが参考になる。
で、詳しく解説しているので一見の価値あり。日本人しかいない社内で利用するのであれば、コミットメッセージは日本語でも構わないとは思う。(下手な英語でわけがわからんよりは日本語でわかった方がマダましという意味)
この記事を書いている須藤功平氏が解説を書いたリーダブルコードで学ぶことにより、人が最短で理解できるための「良いコード」や「忘れても良いコード」を書ける事も重要だ。
発売早々に増刷がかかったようなので、一時的に品薄であるのかもしれない。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) Dustin Boswell、Trevor Foucher、角 征典 |
issue
GitHubのissue機能が他のプロジェクト管理ツールと比較すると違う点が結構あるため、そもそもどういった使い方をするか、使わないかなどをあらかじめ決めておくことが望ましいだろう。
既存のissueシステムを使い続けるのも1つの選択ではある。
レビューの定義
基本的には全てPull Requestで機能が開発されていくので、Pull Requestを取り組む際の基準を明確にしておこう。
- コーディング規約もチェックする?
- 動けばOK?
- テストコードは必須?
などなど、チームの能力に合わせて決めるべし。
また、Pull Requestの取り込みを誰がやるのか、誰がレビューするのかは明確にしておこう。チーム全員がある程度の品質を保てて、全員できる方が望ましい。
Pull Requestを放置されてしまう事が問題になるケースがあるので、Pull Requestを1つ送ったら、Pull Requestを1つ処理するルールなどを設けることも非常に有効である。
service/hooksを活用
JenkinsなどのCIとの連携やdiffをメールで送ったりなど、service/hooksの機能は徹底的に使いこなそう。
これについては、Web+DB PRESS Vol.69でも触れている。
WEB+DB PRESS編集部 |
まとめ
徹底的にやるともっとあるだろうが、GitHubはあくまでツールであるので、本業が疎かにならない程度に効果のある使い方をしていくことが重要だ。
その他、先人達のアイデアや経験をTwitterなどで教えてくれると、とても参考になる人達がいるのではないだろうか。
GitHubを使いたいと思っているチームは下記のイベントで発表されている事例などをうまく使って交渉してみてはどうだろうか。