GitHub ざっくり How to use.

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680230/01e4e165-bcc6-ba71-e2cc-22b4dd199ab4.png)

# はじめに
仕事で 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](###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の強力な助っ人、サブモジュールの使い方を完全解説！](https://qiita.com/itinerant_programmer/items/e400aa944b89774f011c)
- [サブモジュールとは何か？メリットや注意点、git submoduleの使い方やオプションを実例で解説｜プルリクや共同開発時の注意点](https://prograshi.com/general/git/how-to-use-git-submodule/)