GitHub ざっくり How to use.

はじめに

仕事で GitHub を利用してます。プロジェクトによって使い方が異なるので、”自分流”をまとめたいと思います。
今後はチームに「まずは、この Qiita 見て！」って、言いたいです。

リポジトリ作成 (new repository)

単位

• 成果物の単位でリポジトリを作成
• 複数になる場合は、主体リポジトリを必ず作成
  • 例：example-engine, example-engine_sub
• 親子関係になる場合は、"サブモジュール"を積極的に活用

名前

• 英子文字。単語区切りは"-"
• 複数リポジトリになる場合は、メイン名称 + "_" + サブ名称
  • 例：example-engine, example-engine_library-alpha

概要 (Description)

• 超概要を短く記載

プログラムコード (Code)

Branch

• 詳細は、今後投稿予定の「Git」へ期待
• せめて、main, develop, feature/xxx のブランチ

Tags

• "メジャー" . "マイナー" . "ビルド" の構成　※"リビジョン" は利用しない
  • メジャー : 全体指針の変更
  • マイナー : 機能の増減
  • ビルド : 不具合の対応

Releases

• Tag の変更内容を箇条書き
• コードをコンパイルしないでも、パッと戻せるようにビルド結果のアウトプットを添付

README.md

• 概要 : 成果物の概要
• 環境 : 環境の概要
• 起動手順 : 起動手順
  • 特にパラメータなど
• 参照 : 上記項目に関わるリンク

上記以外は、Wiki に記載

課題 (Issues)

Issue

• より小さく、より具体的に記載
• テンプレートを作成して記載内容を統一
  • パス : .github/ISSUE_TEMPLATE/{テンプレート}.md
• 関係する他の Issue がある場合は、"補足"に Issue へのリンクを記載
  • "やること"に手順の 1 つとして、他の Issue を記載しても OK
• 特に下記の登録を忘れがち！
  • Projects, Milestone, Development

テンプレート

• バグ報告テンプレート.md

  ---
  name: "バグ報告テンプレート"
  about: 不具合報告
  title: "[バグ]"
  labels: bug
  assignees: ''
  
  ---
  
  ### 概要 / Overview
  
  ### 再現環境 / Environment
  
  ### 再現手順 / Process
  
  ### 補足 / Supplement
  
  

• 改善テンプレート.md

  ---
  name: "改善テンプレート"
  about: 改善・リファクタ
  title: ''
  labels: ''
  assignees: ''
  
  ---
  
  <!-- すべての項目を埋めなくてよい -->
  ### 概要 / Overview
  
  ### 背景 / Background
  
  ### メリット / Merits
  
  ### やること / What to do
  - [ ] 細かいタスクに分解できているなら書き出す
  
  ### 補足 / Supplement
  
  

Label

ラベル	概要	内容
bug	不具合	機能の誤りや欠陥
environment	環境	インフラの更新
documentation	文書化	ドキュメントの更新
duplicate	重複	課題またはプルリクエストはすでに存在
enhancement	強化	新しい機能またはリクエスト
good first issue	初心者向け課題	初心者でも取り組みやすい課題
help wanted	ヘルプ	ヘルプが必要
invalid	無効	課題として正しくない
operation and maintenance	運用保守	運用保守の課題
question	質問	より詳細が必要
refactoring	リファクタリング	動作を変更せずコードを整理
wontfix	未対応	対応しない
roadmap	ロードマップ	ロードマップレベルのIssue

Milestone

• 下記の単位を検討
  • 期間
  • スプリント
  • バージョン
  • リリース

PR (Pull requests)

PR

• 小さく、小さく PR を登録。レビュアーは 1 PR に変更が多いと大変！
• テンプレートを作成して記載内容を統一
  • パス : .github/pull_request_template.md
• 関係する他の PR がある場合は、前提PR"に PR のリンクを記載
• 特に下記の登録を忘れがち！
  • Projects, Milestone
• マージ : Feature/#99-xxx ブランチから develop ブランチへマージ
  • リリース : develop ブランチから main ブランチへマージ

テンプレート

• pull_request_template.md

  # Pull Request Title
  Feature/#{issue_id} {title}
  
  ## チケット（メインもサブも、関連する Issue を全て記載）
  - #{issue_id}
  
  ## 前提 PR
  - #{pr_id}
  
  ## PRタイプ（必要なものだけ残す）
  - :heavy_plus_sign: 追加修正
  - :new: 新機能
  - :bug: バグ対応
  - :recycle: リファクタリング
  - :book:ドキュメント整備
  - :computer: 開発環境
  - :bullettrain_side: インフラ
  - :white_check_mark: テスト
  - :minidisc: データベース
  
  ## 概要
  
  ## 詳細（UI変更前後、機能変更前後など）
  
  ## レビュー手順（レビュアーが再現できる手順で記載）
  - [ ] 手順1
    - [ ] 手順1.1
  - [ ] 手順2
  
  ## 補足資料（リンク、スクショ、動画など ）
  
  ## その他（レビュワーへの注意点・相談内容・懸念点）
  
  

議論 (Discussions)

利用を検討

• Slack でも OK

利用した体感

• 良い点
  • 散らばらない。一か所にまとまっているので、"ふりかえり"などでも検索が楽だった
  • 綺麗に書ける。Slack よりも気を張って書くので1つ1つが綺麗にまとまってた
• 悪い点
  • 気が付かない。Slack に通知しても、やっぱり Slack 直接の方が明らかにリアクションが早い
  • バラける。チームで頑張っても、やっぱり Slack にも記載しちゃう
  • 気を張る。メリットでもあるが、記載の敷居が Slack よりも高い

自動ワークフロー (Actions)

workflow

• いろいろ作って楽しましょう
• コードパス : .github/workflows
• 詳細は、今後投稿予定の「GitHub Actions」へ期待
• workflow 作成例
  • ビルド
  • デプロイ
  • 自動登録（補完）
  • プルリクエスト

プロジェクト (Projects)

View

• プロジェクトの進め方（ウォーターフォール、アジャイル）で View を決定
• 常設の個人 View は、作成しない

Roadmap View

• プロダクトオーナー(PO)やビジネス側と共通認識のロードマップ
• Layout : Roadmap
• Filter : is:issue -no:milestone label:Roadmap

Roadmap Detail View

• プロダクトオーナー(PO)やビジネス側と共通認識のタスク
• Layout : Table
• Filter : -status:Done label:Roadmap
• Slice by : Milestone

All Issue View

• 開発チームで全ての課題を確認
• Layout : Roadmap
• Filter : is:issue -no:milestone
• Slice by : Priority

Sprint Board View

• 開発チームで Sprint の課題を確認
• Layout : Board
• Filter : sprint:@current

Sprint Table View

• 開発チームで Sprint の課題を確認
• Layout : Table
• Filter : sprint:@current

PR Table View

• 開発チームで PR を確認
• Layout : Table
• Filter : is:pr -status:Done

知識共有 (Wiki)

Home

• プロジェクト概要
  • README.md　へリンク
• プロジェクトゴール
  • なにが出来れば完了なのか
• スケジュール
  • 最初に作成するざっくりスケジュール
    • 詳細スケジュールは Projects にて管理
• Wiki 更新履歴
  • Wiki のページ更新者、更新概要、更新日付

Sidebar

• プロジェクト
  • 概要
  • ゴール
  • 目標
• スケジュール
  • 概算
  • ルール
    • スプリント
  • スケジュール詳細 : Projects
  • 朝会／打合せ
• 設計
  • 基本設計
• 環境
  • 本番環境
  • ステージング環境
  • 開発環境
• プログラム
  • 規約／ルール
• テスト
  • UT
  • PT
  • IT
• 運用
  • 規約／ルール
  • 手順

おわりに

ざっくりとポイントだけ書くつもりでしたが、書き出すといろいろとありますね。
覚えてない事も結構あって、プロジェクトを参考にしながらまとめました。
今後も、機能が増えたり、使い方を変えたりすると思うので、アップデートを反映させる予定です！

今後投稿予定の「Git」、「GitHub Actions」へ期待

---

参考（感謝）

• Gitの強力な助っ人、サブモジュールの使い方を完全解説！
• サブモジュールとは何か？メリットや注意点、git submoduleの使い方やオプションを実例で解説｜プルリクや共同開発時の注意点