サービス名: でももに！

※ SwiftUI リメイク版

卍Github運用について✒卍

卍リポジトリ卍

• 各プラットフォームごとにリポジトリを作る
• リポジトリごとにカンバンを作る

卍Issue卍

• Issueとは
  • 追加する機能を書く(余裕があれば完成予想図なモックがあると嬉しい)
  • スプリントバックログからIssueを書き写す
  • 他、機能の修正提案、挙動が変なんじゃないか、などを話し合うところ
• タイトル命名規則 ([FIX]とか)
  • タイトルを見て要件が分かるようにする
  • そのIssueが何についてのIssueなのか記載する
  • Issueの要件定義
    • (ハロワの場合)
    • テキストラベルをおく
    • テキストラベルの中身を定義する
  • ラベル
    • 緊急
    • なるはや
    • いつでも

卍カンバン卍

参考資料

• スプリントバックログに対応するカンバンを作る
• ToDo、Doing、Review、Done の4カラムで運用する
• 誰がやっているのかはわかるようにしておく (Issueと対応させて、Assigneeを設定する)

卍ブランチ卍

git flowとgithub flowについて

Git flowとGithub flowについて

• git flowで決定
  • 開発ブランチはdevelopにする (defaultブランチにする)
  • develop, main, fix, feature
  • develop: 開発用
  • main: スプリントごとのリリース用
  • fix: バグ修正
  • feature: 機能追加

日本語ブランチは許されません！

• 基本はキャメルケース、多少ブレても良い 以下例

  • feature/*** (機能追加ブランチ)
  • fix/*** (修正ブランチ)

• スプリントごとにマスターにプッシュにするのも良き

卍プルリク卍

• 命名規則

  • prefix
    • 【FEAT】
    • 【FIX】
  • タイトルで伝わるように
  • 日本語でもおｋ

• メッセージ

  • どんな変更なのか簡単に説明が書いてあると良い
  • どんなところをレビューして欲しいかもあるとレビューしやすい

• 粒度

  • 莫大な変更を含むプルリクを出さない。
  • なるべく細かくやる。
  • 余計なことしない。（ついでに他のとこ直すとかしない）
  • 目安は1ファイル分の変更くらいだと見やすい (読み手の存在を意識しながら)

• ラベルの付け方

  • カンバンと一緒

卍レビューの方法卍

• 流し見しがち
  • わかんなくても、ちゃんと見てコメントしてほしい。
  • 積極的に参加してほしい。
  • 自分以外二人のレビューでマージ可能
  • 良識の範囲内でレビューを催促したほうが進みが良い。

卍コミットについて卍

• 粒度

  • プルリクよりも小さい単位。
  • こまめにコミットするよう心がける。

• コミットメッセージ

  • 変更内容がわかるように書く。
  • 日本語でおｋ！！