github-development-rule-20181006.md

現在制作中

branchの生成・命名規則

feature/f3-network/1/pollenjp/xxx

基本的にissueを作成し、そこにそのブランチで追加する機能(ブランチを切った理由)を明記する. issue作成規則もよく読むこと.

ただし、issue作成がよくわからなければチームごとにそれぞれで定めてください.

• 各チームはfeature/<チーム名>/devのブランチを作成し、基本的に各チームの開発はこのブランチで統合していく。
  • feature/f3-software/dev
  • feature/f3-hardware/dev
  • feature/f3-network/dev
  • feature/f3-materials/dev
• 各チームの人は対応するdevブランチからブランチを切る
• ブランチの命名はfeature/<チーム名>/<番号>/<ユーザ名>/<内容>を軸とする
  • <番号>にはissue作成時に生成される番号を書く。
  • issueを作成・指定しなければfeature/<チーム名>/<ユーザ名>/<内容>
  • 例: feature/f3-network/1/pollenjp/xxx
  • 例: feature/f3-network/pollenjp/xxx
  • 同一issueを複数人で担当する際はユーザ名を省略してもよい(issueを一人単位に分割するほうが好ましい)
  • <番号>をこの位置に書いている理由
    • ブラウザ上ですぐに確認しうる長さであるため(これ以上後ろに記述すると省略されてぱっと見では確認できない)
• 複数チームにまたがる作業の時はfeature/<番号>/<ユーザ名>/<内容>
• チーム間でのブランチの統合は各チームリーダーが担当することが望ましい
• その他の例外に関しては適宜慣れている人の支持を仰いだりなどして判断する
• Tips
  • リモートブランチの削除情報などもfetchする際は-p, --pruneをつける

    • $ git fetch --prune
      

issueの生成規則

• ブランチを切る
  • ブランチを切る際にそのブランチで追加する機能を明記する
  • Assigneesで対象のユーザを選択
  • issueに対してはチーム名ラベルをつける
  • 適宜追加のラベルをつける(無闇矢鱈に新たなラベルを生成するのは良くない)
  • プルリクエストが承認されたタイミングでissueを閉じる。
    • GitHubの場合プルリクエストメッセージにキーワードをつけることで承認後自動で閉じてくれる。
    • https://help.github.com/articles/closing-issues-using-keywords/
• バグの発見
  • 実行環境・実行プログラムファイル(commit-id)・実行コマンドなどできるだけ詳細にかく。

Projectsの使用

各チームごとにProjectsを作成することを推奨する。

• issueなどと紐付いたタスク管理を行うことができる。