こんにちわ=)
初学者の皆さんは「Issueドリブン開発」や、Gitのブランチ名にも命名規則があるのを知ってますでしょうか？
自分は「聞いたことあるな」くらいにしか考えていませんでしたが、最近は開発設計の勉強もしているところなのできっちり勉強しようと思います。
自分はgitでブランチを切るときに毎回、「ブランチ名なににしよっかなー？」とか毎回適当に決めちゃっていました。
クラス名やテーブル名にも命名規則があるように、ブランチにもルールがあるんじゃないかな？って調べたら案の定ありました。。
いつまでも知らないままにするのは良くないので、ちゃんと勉強と実践をしていきたいと自戒を込めてこの記事を書きました。
自分なりの解釈が多分に含まれますが、ぜひご覧ください。
issueドリブン開発のメリット・デメリット
きちんと厳密にルールを守らせる必要はありますが、issueとブランチを1セットにすることの恩恵はかなりあると思っています。
メリット
- 修正したissueを参考にしようとしたときにわかりやすい。
- 作成されたブランチがどのissueに関連したものかが明確になる
- コミットが大きくなりすぎないためコードレビューしやすくなる。
デメリット
変数名の変更みたいな「これのためにissue立てるのか？！」みたいな細かな修正の際に個人の裁量が難しい。一言で言えば「少し面倒くさい」ｗ
issueとは
Issueとは、Github上でタスク管理できるToDoリストみたいなものです。
issueを書くと、下記の画像の**#番号**のような番号が発行され、これは後にbranch作成の時に必要になってきます。
自分が必要な機能や気になるバグなどを見つけた時には、issueを書くことをクセ付け、相手に依頼された際は「isseuで書いてください」と伝えることで、当事者同士のふんわりとした依頼や修正が少なくなり、結果的に組織的な開発がしやすくなります。
issueの書き方
issueはタイトルと詳細な内容を書くことが出来ます。
タイトルは簡潔に分かりやすく書き、内容は詳しく書きたいことがある際、画像を添付したりマークダウンで書くことで、より分かりやすいissueを作成することができます。
Issueドリブン開発の流れ
以下は「Webサイトのメニューをハンバーガーメニューに変更したい」となった際の一例です。
- Github上で、やりたいことを記載したIssueを立てる。(issue番号は#1と仮定)
- 発行されたIssue番号を使い、
feature/#1_replace_to_hamburger_menuというブランチを作成。 - 開発進める。
- 開発完了したらdevelopブランチにマージコミット。
この際、close #12などとコミットメッセージに記述すると、自動的にIssueが閉じられるので、覚えておきましょう。
ブランチの作成の仕方
以下がブランチの命名の仕方です。
$ git branch ブランチ名/#issue番号_動詞_機能
ブランチの記述の手順は以下の流れになります。
- ブランチと関連する発行されたissue番号を記述
- add, remove, updateなどの動詞を記述
- 追加する機能を簡潔に記述
feature- と hotfix- の後には任意のわかり易い名前をつけてください。
ブランチ命名のサンプル
**「すでに設置済みmenuをハンバーガーに変更する」**といった場合はこんな感じに記述します。
feature/#番号_replace_to_hamburger_menu
こちらは今自分が開発中のアプリで実際に立てたブランチで、「開発中のクイズ画面のUI」を置いておくためのブランチとして作成しました。
develop/#13_coding_quizUI
まとめ
今回はissueドリブン開発について学習してみました。
現在個人開発で実践していますが、GitHubの使い方の非常に良い練習にもなります、現場に出ていない方も取り入れてみてはいかがでしょうか？
おつかれさまでした！ﾟ=)