Pull Request 以外のプロマネやコミュニティ系の機能は、基本的に無効にしておきたい気持ちはある。 Securty 系は一元管理したい。
| カテゴリ | 機能名 GitHub/GitLab | 役割・提供機能 | 管理・判断方針の例 |
|---|---|---|---|
| PM | Issues / Issues | バグ報告、タスク管理 | Must: 実装タスク・バグはここで管理。 |
| PM | Projects / Boards | カンバン、ロードマップ | Should: 複数リポジトリを横断する進捗管理に使用。 |
| PM | Milestones | 期限、リリース目標 | Should: バージョンごとのゴールを明確化するために使用。 |
| Communication | Discussions / Epics | Q&A、アイデア出し、雑談 | Arbitrary: フロー情報はSlack、ストック議論はここで。Issueと区別する。 |
| Communication | Wiki / Wiki | 長文ドキュメント、仕様書 | Triangle: コード管理外のドキュメント用。ただし docs/ ディレクトリ（Markdown）での管理を優先する場合あり。 |
| Development | Pull(Merge) Requests | コードレビュー、マージ | Must: コード変更の唯一の入り口。 |
| Development | Actions / CI/CD | 自動テスト、デプロイ | Must: .github/workflows で定義。手動オペレーションを廃止する。 |
| Security | Dependabot / Dep Scan | 依存関係の脆弱性検知・更新 | Must: 塩漬け防止。自動PRを作成させる。 |
| Security | Code Scanning | 静的解析 (SAST) | Should: セキュリティ品質のベースライン担保。 |
大体どこに行っても通用する普遍的なやつ
- README.md
- LICENSE
- (CHANGELOG.md)
GitHub と GitLab の両方で有効なデファクトスタンダードなもの
- CONTRIBUTING.md
- CODE_OF_CONDUCT.md
- SECURITY.md
- CITATION.cff
.github/ や .gitlab/ ディレクトリにあるやつはプラットフォーム依存。このへんはちゃんと整理されてる感じはある。
逆にプラットフォーム依存でないもの（renovate.json とか）は、リポジトリルートにおいちゃってもいいかもしれない。
でも結局マスターリポジトリをどこにするか、みたいな話はあると思うので、 .github/ 以下に置いたほうが無難かも。
- node_module
- phplib
- go mod
- Ruby Gem
Webアプリケーションの分類（State of JS 2025 の再整理） https://survey.devographics.com/ja-JP/survey/state-of-js/2025/outline/8#js_app_patterns
ブラウザ上でアプリが完結するタイプ。APIサーバーと疎結合。
- SPA (Single Page Application): 初回ロード後はJSでDOMを書き換える。
- CSR (Client-Side Rendering): SPAの描画手法。
- Offline-First / PWA: Service Worker を使い、ネットワーク切断時も動作することを前提としたSPA。
ビルド時にHTMLを確定させるタイプ。CDN配信がメイン。
- SSG (Static Site Generation): すべて事前にHTML化。
- Jamstack: SSG + API + Serverless Functions の構成全体を指す。
サーバーがリクエストのたびに介在するタイプ。Node.js等のランタイム管理が必要。
- SSR (Server-Side Rendering): リクエスト毎にサーバーでHTML生成。
- ISR (Incremental Static Regeneration): ベースはSSGだが、有効期限切れページへのアクセス時にサーバーサイドで再ビルドを行う。
- MPA (Multi-Page Application): 古典的なWebサイト。ページ遷移ごとにHTMLを全取得する。
- Islands Architecture (Partial Hydration): ベースは静的HTML（MPA/SSG）だが、インタラクティブな部分（島）だけが独立してJSを実行する（Astro, Fresh等）。
CLIアプリは「ユーザーとどう対話するか（Interaction Model）」で分類すると、必要なライブラリや設計が大きく変わります。npx か binary かは「配布方法」であり、以下は「中身の作り」の話です。
- パターン1: One-Shot (Command / Flags) コマンドを一発叩いて終了するタイプ。UNIX哲学（各プログラムは一つのことをうまくやる）に基づく。
- パターン2: Interactive (Wizard / Prompts) ユーザーに質問を投げかけ、回答に応じて進むタイプ。
- パターン3: TUI (Text User Interface) ターミナル全体を使ってリッチなGUIのような操作を提供するタイプ。常駐して操作することが多い。
vimhtopk9s - パターン4: Subcommand Style (Git Style) 上記1〜3の複合だが、大規模CLIで採用される構造。
dockerkubectl