Merge pull request #1 from su-its/docs/repository-settings

Docs/repository settings

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,27 @@
+## チケットへのリンク
+
+- https://github.com/orgs/su-its/projects/example-hogehoge-fugafuga
+
+## やったこと
+
+- このプルリクで何をしたのか？
+
+## やらないこと
+
+- このプルリクでやらないことは何か？（あれば。無いなら「無し」で OK）（やらない場合は、いつやるのかを明記する。）
+
+## できるようになること（ユーザ目線）
+
+- 何ができるようになるのか？（あれば。無いなら「無し」で OK）
+
+## できなくなること（ユーザ目線）
+
+- 何ができなくなるのか？（あれば。無いなら「無し」で OK）
+
+## 動作確認
+
+- どのような動作確認を行ったのか？　結果はどうか？
+
+## その他
+
+- レビュワーへの参考情報（実装上の懸念点や注意点などあれば記載）

docs/README.md

@@ -0,0 +1,8 @@
+# DocumentFor-ITS-TypingDev
+
+## コンテンツ一覧
+
+- 💻 [Get Started](get-started.md)
+- 🗄️ [ディレクトリ構成](directory-strategy.md)
+- 📝 [コミット戦略](commit-strategy.md)
+- 🌲 [ブランチ戦略](branch-strategy.md)

docs/branch-strategy.md

@@ -0,0 +1,90 @@
+# ブランチ戦略ガイド
+
+このガイドでは、効率的で整理された開発フローを促進し、コードベースの安定性を保持するためにチームが従うべきブランチ戦略を定義します。
+
+## メインブランチ
+
+- **main**: 本番環境にデプロイ可能な状態を常に保ちます。変更はプルリクエストを通じてのみマージされます。
+
+## 開発ブランチ
+
+- **develop**: 新機能、バグ修正、リファクタリングなどの開発作業用の主要ブランチです。`main`から分岐し、開発が完了した機能はこのブランチにマージされます。
+
+## 機能ブランチ (`feature/`)
+
+機能ブランチは、新しい機能の開発や既存機能の大幅な改善を行うために使用されます。これらのブランチは、特定の機能や目的に集中することで、開発プロセスをより管理しやすくすることを目的としています。
+
+#### 命名規則
+
+機能ブランチの名前は、`feature/`の接頭辞で始まり、その後に開発される機能や改善点を簡潔に説明するキーワードが続きます。名前は機能の目的を反映し、他の開発者がブランチの内容を簡単に理解できるようにする必要があります。
+
+例:
+
+- `feature/user-authentication`
+- `feature/payment-integration`
+- `feature/refine-search-algorithm`
+
+#### 開発フロー
+
+1. **分岐**: 新しい機能の開発を開始する際には、常に最新の`develop`ブランチから`feature/`ブランチを分岐させます。
+2. **開発**: 機能ブランチ内で必要な全ての開発作業を行います。これには、コーディング、単体テストの作成、ドキュメントの更新などが含まれます。
+3. **定期的な更新**: 開発中に`develop`ブランチが更新された場合は、変更を機能ブランチに取り込むために定期的にリベースするかマージします。これにより、最終的なマージプロセスを容易にし、衝突の可能性を減らします。
+4. **コードレビュー**: 機能が完成し、テストをパスしたら、プルリクエストを作成して`develop`ブランチにマージする前にチームメンバーのコードレビューを受けます。
+5. **マージ**: レビューが完了し、プルリクエストが承認されたら、機能ブランチを`develop`にマージします。マージ後、ブランチはクローズされ、必要に応じて削除されます。
+
+#### ベストプラクティス
+
+- **小さな単位でのコミット**: 機能ブランチ内の作業を小さな単位に分割し、各変更に対して明確なコミットメッセージを使用してコミットします。
+- **機能の単一性**: 一つの機能ブランチは一つの主要な機能に焦点を当てるべきです。複数の機能を同時に開発する場合は、それぞれに対して別々のブランチを使用します。
+- **透明性の維持**: プルリクエストやブランチの説明には、変更の目的や機能の概要、テストケース、特に注意が必要な点など、十分な情報を含めて他のチームメンバーとの透明性を確保します。
+
+機能ブランチ戦略を適切に使用することで、チームはより効率的に機能を開発し、プロジェクトの全体的な品質とコラボレーションを向上させることができます。
+
+## タイプ別ブランチ
+
+### CI ブランチ (`ci/`)
+
+- **目的**: CI (Continuous Integration) 設定ファイルやスクリプトへの変更。
+- **命名規則**: `ci/update-pipeline`, `ci/add-linting`
+- **マージ先**: `develop`
+
+### ドキュメントブランチ (`docs/`)
+
+- **目的**: ドキュメントの作成や更新。
+- **命名規則**: `docs/update-readme`, `docs/add-contributing-guide`
+- **マージ先**: `develop`
+
+### バグ修正ブランチ (`fix/`)
+
+- **目的**: バグの修正。
+- **命名規則**: `fix/login-error`, `fix/memory-leak`
+- **マージ先**: `develop`
+
+### リファクタリングブランチ (`refactor/`)
+
+- **目的**: コードの構造を改善するが、外部に見える挙動には影響を与えない。
+- **命名規則**: `refactor/cleanup-service`, `refactor/optimize-function`
+- **マージ先**: `develop`
+
+### スタイル調整ブランチ (`style/`)
+
+- **目的**: コードフォーマットやコーディング規約の遵守。
+- **命名規則**: `style/fix-indentation`, `style/apply-lint-rules`
+- **マージ先**: `develop`
+
+### テストブランチ (`test/`)
+
+- **目的**: 新しいテストの追加や既存テストの修正。
+- **命名規則**: `test/add-login-tests`, `test/fix-cart-tests`
+- **マージ先**: `develop`
+
+## マージ戦略
+
+- 全てのマージはプルリクエストを通じて行われ、コードレビューが必要です。
+- スクワッシュマージを使用して履歴を整理することが推奨されます。
+- 必要に応じて、`develop`や`main`からのリベースを使用してブランチを最新の状態に保ちます。
+
+## ブランチの維持
+
+- マージが完了したブランチは、その作業が`develop`または`main`に統合された後に削除することが推奨されます。
+- 定期的にブランチをレビューし、もはや使用されていない古いブランチをクリーンアップします。

docs/commit-strategy.md

@@ -0,0 +1,47 @@
+# コミットメッセージの形式
+
+コミットメッセージは以下の形式に従うべきです:
+
+```
+<型>[任意 スコープ]: <タイトル>
+
+[任意 本文]
+
+[任意 フッター]
+```
+
+- **型**: コミットの種類を表します。
+- **スコープ**: コミットが影響を与える範囲（オプション）。
+- **タイトル**: コミットの主な変更点を簡潔に説明します。
+- **本文**: 変更内容の詳細な説明（オプション）。
+- **フッター**: 関連する Issue や Merge Request の参照など、追加情報（オプション）。
+
+## コミットの型
+
+コミットメッセージで使用できる「型」は以下の通りです:
+
+- **build**: ビルドシステムや外部依存関係に影響を与える変更。
+- **ci**: CI(Continuous Integration)設定ファイルやスクリプトへの変更。
+- **docs**: ドキュメントのみの変更。
+- **feat**: 新しい機能の追加。
+- **fix**: バグの修正。
+- **perf**: パフォーマンスを向上させるコード変更。
+- **refactor**: バグ修正や新機能追加を行わずに、既存コードの改善・整理。
+- **style**: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの欠落など）。
+- **test**: テストの追加や既存テストの修正。
+
+## ベストプラクティス
+
+- **タイトルは明確で簡潔に**: タイトル行は 50 文字以内で変更の要約を述べるべきです。
+- **本文で詳細を説明**: タイトルだけでは伝えきれない変更の動機やコンテキストを本文で説明してください。本文は 72 文字ごとに改行するのが一般的です。
+- **フッターで参照を追加**: 関連する Issue や Merge Request がある場合は、フッターにその参照を追加してください。
+
+## 実践例
+
+```
+feat[ログイン機能]: 二要素認証を追加
+
+ユーザーのセキュリティを向上させるため、ログインプロセスに二要素認証を追加しました。ユーザーは、パスワードに加えて、モバイルデバイスに送信されたコードを入力する必要があります。
+
+Closes #123
+```

docs/directory-strategy.md

@@ -0,0 +1,19 @@
+# ディレクトリ戦略ガイド
+
+このガイドは、プロジェクトのルートディレクトリ内に存在する`frontend`と`backend`ディレクトリの構造と目的を定義します。適切なディレクトリ構造は、プロジェクトの可読性、拡張性、およびメンテナンスのしやすさを高めます。
+
+## ルートディレクトリ
+
+プロジェクトのルートディレクトリには、主に二つのディレクトリ、`frontend`と`backend`が含まれます。これにより、フロントエンドとバックエンドのコードが明確に分離され、開発の効率化と専門化が促進されます。
+
+### `frontend/`
+
+フロントエンドディレクトリは、ユーザーインターフェースとクライアントサイドのロジックを含むファイル群を格納します。このディレクトリ内では、さらに詳細なサブディレクトリ構造を定義して、コンポーネント、サービス、ユーティリティ、スタイルなどを整理します。
+
+### `backend/`
+
+バックエンドディレクトリは、サーバーサイドのロジック、データベースの操作、API エンドポイントなどを管理します。このディレクトリもまた、機能や役割に基づいてサブディレクトリに分けることが推奨されます。
+
+## サブディレクトリ
+
+それぞれのディレクトリに docs/ディレクトリが用意されているので、それぞれのディレクトリの詳細についてはそちらを参照してください。

docs/get-started.md

@@ -0,0 +1,17 @@
+# 💻 Get Started
+
+## 事前にインストールするソフトウェア
+
+**Comming soon...**
+
+## ソースコードのクローン
+
+以下のコマンドを入力して任意のディレクトリにレポジトリを clone してください。
+
+```
+$ git clone https://github.com/su-its/typing.git
+```
+
+## アプリケーションの立ち上げ
+
+**Comming soon...**