※ SwiftUI リメイク版
- 各プラットフォームごとにリポジトリを作る
- リポジトリごとにカンバンを作る
- Issueとは
- 追加する機能を書く(余裕があれば完成予想図なモックがあると嬉しい)
- スプリントバックログからIssueを書き写す
- 他、機能の修正提案、挙動が変なんじゃないか、などを話し合うところ
- タイトル命名規則 ([FIX]とか)
- タイトルを見て要件が分かるようにする
- そのIssueが何についてのIssueなのか記載する
- Issueの要件定義
- (ハロワの場合)
- テキストラベルをおく
- テキストラベルの中身を定義する
- ラベル
- 緊急
- なるはや
- いつでも
- スプリントバックログに対応するカンバンを作る
- ToDo、Doing、Review、Done の4カラムで運用する
- 誰がやっているのかはわかるようにしておく (Issueと対応させて、Assigneeを設定する)
- git flowで決定
- 開発ブランチはdevelopにする (defaultブランチにする)
- develop, main, fix, feature
- develop: 開発用
- main: スプリントごとのリリース用
- fix: バグ修正
- feature: 機能追加
日本語ブランチは許されません！
-
基本はキャメルケース、多少ブレても良い 以下例
- feature/*** (機能追加ブランチ)
- fix/*** (修正ブランチ)
-
スプリントごとにマスターにプッシュにするのも良き
-
命名規則
- prefix
- 【FEAT】
- 【FIX】
- タイトルで伝わるように
- 日本語でもおｋ
- prefix
-
メッセージ
- どんな変更なのか簡単に説明が書いてあると良い
- どんなところをレビューして欲しいかもあるとレビューしやすい
-
粒度
- 莫大な変更を含むプルリクを出さない。
- なるべく細かくやる。
- 余計なことしない。（ついでに他のとこ直すとかしない）
- 目安は1ファイル分の変更くらいだと見やすい (読み手の存在を意識しながら)
-
ラベルの付け方
- カンバンと一緒
- 流し見しがち
- わかんなくても、ちゃんと見てコメントしてほしい。
- 積極的に参加してほしい。
- 自分以外二人のレビューでマージ可能
- 良識の範囲内でレビューを催促したほうが進みが良い。
-
粒度
- プルリクよりも小さい単位。
- こまめにコミットするよう心がける。
-
コミットメッセージ
- 変更内容がわかるように書く。
- 日本語でおｋ！！