format (#192)

* Test * format
future-architect · Dec 20, 2024 · c93a27e · c93a27e
1 parent bce84fc
commit c93a27e
Show file tree

Hide file tree

Showing 2 changed files with 10 additions and 8 deletions.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -1,6 +1,8 @@
 name: ci
 
 on:
+  push:
+    branches: [master]
   pull_request:
     branches: [master]
 

diff --git a/documents/forGitBranch/git_branch_standards.md b/documents/forGitBranch/git_branch_standards.md
@@ -295,19 +295,19 @@ featureブランチでの作業中に、developブランチが更新された場
 
 プリリクエストの承認（Approve）をもらった後、マージはレビュアー／レビュイーのどちらが行うべきか議論になる場合がある。
 
-| 観点    | レビュアー派                                   | レビュイー派閥                                        |
-|-------|------------------------------------------|------------------------------------------------|
-| 説明    | 開発者の責務が、developブランチにマージするまでという役割分担の場合に有効 | 各開発者がその機能のリリースについて責任を負うモデルの場合に有効               |
-| 生産性   | ⚠️レビュアーがブロッキングになりがち                      | ✅️高い。コメントはあるがApproveしたので、適時対応してマージして、といった運用が可能 |
-| 統制    | ✅️レビュアーが管理しやすい                           | ✅️メンバーの自主性に依存                                  |
-| 要求スキル | ✅️低い。中央で統制を書けやすい                         | ⚠️開発メンバーの練度が求められる                              |
+| 観点       | レビュアー派                                                              | レビュイー派閥                                                                       |
+| ---------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
+| 説明       | 開発者の責務が、developブランチにマージするまでという役割分担の場合に有効 | 各開発者がその機能のリリースについて責任を負うモデルの場合に有効                     |
+| 生産性     | ⚠️レビュアーがブロッキングになりがち                                      | ✅️高い。コメントはあるがApproveしたので、適時対応してマージして、といった運用が可能 |
+| 統制       | ✅️レビュアーが管理しやすい                                               | ✅️メンバーの自主性に依存                                                            |
+| 要求スキル | ✅️低い。中央で統制を書けやすい                                           | ⚠️開発メンバーの練度が求められる                                                     |
 
 上記にあるように、そのプルリクエストで実装した機能を、本番環境にデリバリーする責務をどちらに持たせるかという観点で、意思決定することが多い。
 
 本規約の推奨は以下。
 
-* プロダクトオーナー（業務側）などでリリースタイミングを完全にコントロールしたいといった分業制を取る場合は、レビュアーがマージする
-* 各開発者により自律性を持たせ、アジャイル的に生産性を重視するのであれば、レビュイーがマージする
+- プロダクトオーナー（業務側）などでリリースタイミングを完全にコントロールしたいといった分業制を取る場合は、レビュアーがマージする
+- 各開発者により自律性を持たせ、アジャイル的に生産性を重視するのであれば、レビュイーがマージする
 
 ## 3. 永続ブランチ間で変更を取り込む