コミット・PR単位などよりうまくGitを活用するために再考

## 概要
- 自分のコミット・PRがめちゃくちゃにわかりづらいと感じているため、どのようにすべきか・どうしたら解決できるかを再考する
- 現状の自分がどのようにすべきかの指針を示す
- ただ我流でやるには限界を感じたため、改めて考えたい

## 以前の記事

https://qiita.com/koinunopochi/items/9bc17ef40b0d0d633480

## 以前から現在（2週間ぐらい？）の変化

**＞＞＞＞＞＞目安作成前＞＞＞＞＞＞＞**
1. PRの肥大化
1. PRの目的の分散
1. コミット粒度が大きい

**＞＞＞＞＞＞目安作成後＞＞＞＞＞＞＞**
対策：
1. PRに含む変更のあるファイルは10ファイル以内程度
1. まとめブランチを作成する

PRの目的を意識した結果`3ファイル・1コミット`のPRなどが大量に生まれてしまった

## 過去を踏まえた現状のGit・GitHubの利用法の問題
### PRにおける問題

1. PRにすべき単位が不明確で、10ファイルの目安に到達しないことが多い
1. PRにおいて特に`コードレビューで見てほしいことがない場合の対処法`

### コミットにおける問題

1. コミットメッセージがWhyではなく、Done・Doになっている
1. コミット粒度の基準が不明確である
1. fixを多用し過ぎている
1. 意思決定のプロセスが適切でない

## どのようにしていくべきか

https://qiita.com/_mi/items/f477e95a864474187e3d

主にこのサイトを参考に自分の形に落とし込んでいきたいと思う

### PRにおける問題の対策

#### 1. PRに含む変更のあるファイルは10ファイル以内程度

原因の考察：
PRの単位が明確でないことでコミット数が少ないなどで不安になってしまっている

:::note info
PRは1単位の目的と定める
:::

1単位の目的とは：

>１単位の目的と言っているのは例えば、
>
>（１単位の）新規機能の追加
（１単位の）不具合の修正
（１単位の）リファクタリング

参考：https://qiita.com/_mi/items/f477e95a864474187e3d

特に参考サイトを読んで感じたこととしては、機能開発・修正においてもテストの作成や変更があるため、本来であれば変更するファイルはもう少し増えるはずである

**今のプロジェクトではテストの作成を行っていないため、ファイルの変更数が少なくなってしまっている**

⇒スピード開発を行っていたが切り替えのタイミングであるので、テストを行う本来の開発に戻す

#### 2.PRにおいて特に`コードレビューで見てほしいことがない場合の対処法`

:::note info
テンプレート化　＋　サンプルを追加することで、何を書けばよいのかを明確にする
:::


>**レビューすべき箇所を明示してほしい**
>実装物の品質を見るにあたり、レビュワーとしては「**何を実装したのか、なぜ実装したのか**」が明確になっているとレビューがスムーズに行えそうです。
>
>- 趣旨
>- 実装した背景
>    - 実装チケットのリンクなど貼っておくと良さそう
>- レビューが必要な箇所
>    - 実装した箇所の明示
>    - レビュー方法
>        - 実際に開発環境を動かしてほしいのか、どのように動かせば良いのか
>    - 重点的にレビューして欲しい箇所
>
>これらはPull Requestのdescriptionやタイトルに記載することになるかと思います。プロジェクトによって記載内容の方向性など変わってくると思うので、新規参入者にも伝わりやすいようPull Requestのテンプレートが欲しいところです。
>
>また、細かな部分で補足事項があるのであれば、コメントにメモとして残してもらえると良さそうです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/39b3aacd-79f6-3dd9-b130-ad04911a255d.png)

参考サイト：https://qiita.com/marumaru0113/items/c53db580b812f8f6d4da#%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%99%E3%81%B9%E3%81%8D%E7%AE%87%E6%89%80%E3%82%92%E6%98%8E%E7%A4%BA%E3%81%97%E3%81%A6%E3%81%BB%E3%81%97%E3%81%84

##### **自分に置き換えてテンプレートを作成する：**
```md:テンプレート
# <!-- 管理画面の追加 -->
## 実施タスク
[対象のissue] : <!-- ここを置き換える -->

## 実施内容
<!-- 作成内容・何を変更したか -->
<!-- 過去形で箇条書きで記載する -->

<!-- 例： -->
<!-- - 管理画面の作成を行いました -->
<!-- - 管理画面周りのUIテストコードを追加しました -->

## レビューしてほしいこと
<!-- 実装した箇所の明示 -->
<!-- 全体としてコードについてよりかは実装結果・内容について聞く -->
### 実装した箇所
<!-- 変更したURLパス・対象の画像 -->

<!-- 例： -->
<!-- 変更したURLパス -->

<!-- 【変更前の対象の画像】 -->
<!-- 画像パス -->

<!-- 【変更後の対象の画像】 -->
<!-- 画像パス -->

### 重点的にレビューしてほしいこと
<!-- **レビューしてほしい内容：** -->
<!-- 箇条書きでレビュー方法を記載する -->

<!-- 例 -->
<!-- テストケースに過不足がないこと -->

## 備考
<!-- 実装できていない点・不安・今後の予定などを記載する -->

<!-- 例 -->
<!-- - 管理画面で表示するモーダルについては、別PRで実装を行います -->

```

### コミットにおける問題
#### 1. コミットメッセージがWhyではなく、Done・Doになっている

:::note info
なぜそのようにしたかを意識して記載する
:::

##### 特にDoneで書く癖があるため、コミットメッセージをテンプレート化する

```sh:コミットメッセージテンプレート
なぜなら、「[実際のメッセージ]」という理由で、[このように do ]した
```

助長的に思えるが、Whyで書く癖をつけるためにテンプレート化する

**実際のイメージ：**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/a64a9546-2d53-eb37-5f61-43edaed7de8b.png)


#### 2. コミット粒度の基準が不明確である

現在は`とりあえずコミット`という形をほとんどとっていないが、とりあえずコミットを行い細かい粒度のコミットを作成する

⇒ `git rebase`を用いてコミットを修正・まとめる

**1. コミットメッセージがWhyではなく、Done・Doになっている**で作成したものが利用できるかを意識して行う


#### 3. fixを多用し過ぎている

原因：プレフィックスを覚えきれていないためである

よく利用するプレフィックスをまとめる

https://qiita.com/numanomanu/items/45dd285b286a1f7280ed

ここでは、Angularのものを参考に利用している

参考にしながらプレフィックスを作成したいと思う

* **feat**: 新機能の追加
* **fix**: バグ修正
* **docs**: ドキュメントのみの変更
* **style**: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの欠落など）
* **refactor**: バグを修正せず、新機能も追加しないコードの変更
* **perf**: パフォーマンスを改善するコードの変更
* **test**: 不足しているテストの追加や既存のテストの修正
* **chore**: ビルドプロセスや補助ツール、ドキュメント生成などのライブラリの変更
* **rename**: ファイル名を変更
* **move**: ファイルの移動
* **delete**: ファイル・コメントの削除

#### 4. 意思決定のプロセスが適切でない

原因：目についた流れで実行している

:::note warn
テストを現在作成していないため、テストを書き始めてから改めて良い流れを考える
:::


## テンプレート早見
### PRメッセージ

```md:テンプレート
# <!-- 管理画面の追加 -->
## 実施タスク
[対象のissue] : <!-- ここを置き換える -->

## 実施内容
<!-- 作成内容・何を変更したか -->
<!-- 過去形で箇条書きで記載する -->

<!-- 例： -->
<!-- - 管理画面の作成を行いました -->
<!-- - 管理画面周りのUIテストコードを追加しました -->

## レビューしてほしいこと
<!-- 実装した箇所の明示 -->
<!-- 全体としてコードについてよりかは実装結果・内容について聞く -->
### 実装した箇所
<!-- 変更したURLパス・対象の画像 -->

<!-- 例： -->
<!-- 変更したURLパス -->

<!-- 【変更前の対象の画像】 -->
<!-- 画像パス -->

<!-- 【変更後の対象の画像】 -->
<!-- 画像パス -->

### 重点的にレビューしてほしいこと
<!-- **レビューしてほしい内容：** -->
<!-- 箇条書きでレビュー方法を記載する -->

<!-- 例 -->
<!-- テストケースに過不足がないこと -->

## 備考
<!-- 実装できていない点・不安・今後の予定などを記載する -->

<!-- 例 -->
<!-- - 管理画面で表示するモーダルについては、別PRで実装を行います -->
```


### コミットメッセージ
```sh:コミットメッセージテンプレート
なぜなら、「[実際のメッセージ]」という理由で、[このように do ]した
```
### プレフィックス

* **feat**: 新機能の追加
* **fix**: バグ修正
* **docs**: ドキュメントのみの変更
* **style**: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの欠落など）
* **refactor**: バグを修正せず、新機能も追加しないコードの変更
* **perf**: パフォーマンスを改善するコードの変更
* **test**: 不足しているテストの追加や既存のテストの修正
* **chore**: ビルドプロセスや補助ツール、ドキュメント生成などのライブラリの変更
* **rename**: ファイル名を変更
* **move**: ファイルの移動
* **delete**: ファイル・コメントの削除