Skip to content

Commit

Permalink
:::tip (#153)
Browse files Browse the repository at this point in the history
  • Loading branch information
ma91n authored Jul 23, 2024
1 parent 5338b83 commit 6432fc8
Show file tree
Hide file tree
Showing 2 changed files with 24 additions and 20 deletions.
30 changes: 16 additions & 14 deletions documents/forGitBranch/Gitブランチフロー規約.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ meta:

また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。

# はじめに
## はじめに

本ドキュメントはGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意いただきたい。

Expand All @@ -39,7 +39,7 @@ meta:
| ---------------- | ------------------------------------------| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- |
| GitHub Flow | `main`<br> | 最小のブランチ管理パターンで、開発人数が少なく、検証作業は全員で行う場合に有効。<br>マージの都度本番環境へデプロイする前提。 || ・個人開発<br>・プロジェクト初期フェーズで断面管理を厳密に行わない場合 |
| Lite GitLab Flow | `main`<br>`develop`<br>`feature`<br>`topic`<br> `hotfix` | GitHub Flowに`develop`ブランチを追加するパターン。(特定の呼称はないのでLite GitLab FLowと命名。)<br>`main`ブランチをプロダクトリリースブランチとし、開発中ソースコードとは分ける。 || ・本番リリース済みプロダクトの開発などで、一定品質を保証する必要がある場合<br>・開発作業とリリース作業が並行しないチーム構成である場合 |
| GitLab Flow | `main`<br>`develop`<br>`release` <br>`feature`<br>`topic` <br> `hotfix`z | GitHub Flowに`develop`ブランチと`release`ブランチを追加するパターン。<br>GitLab Flowでは`main`ブランチを`production`ブランチ、`release`ブランチとを`pre production`ブランチと呼称するが、本規約では`main`/`release`に統一する。 || ・リリース作業と開発作業が並行して行われる場合<br> ・断面を指定して複数テスト環境にデプロイしたい場合 |
| GitLab Flow | `main`<br>`develop`<br>`release` <br>`feature`<br>`topic` <br> `hotfix` | GitHub Flowに`develop`ブランチと`release`ブランチを追加するパターン。<br>GitLab Flowでは`main`ブランチを`production`ブランチ、`release`ブランチとを`pre production`ブランチと呼称するが、本規約では`main`/`release`に統一する。 || ・リリース作業と開発作業が並行して行われる場合<br> ・断面を指定して複数テスト環境にデプロイしたい場合 |

### 変則的なパターン

Expand Down Expand Up @@ -133,18 +133,20 @@ featureブランチのマージ後、マイナーバージョン(あるいは
3. メインの開発ブランチの変更を頻繁に取り込む場合、同じようなコンフリクトの解消を何度も求められる可能性があること
- GitのRerereを有効化する(`git config rerere.enabled true`)ことでコンフリクトの解消を記録し、繰り返しの操作を自動化できる

> [!NOTE]
> 強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した下表の調査結果においてForce Push運用による支障は無いと言える。
>
> - 「a.履歴保持」: Force Pushを行い、GitHub投稿したレビューコメントが履歴として何かしらのページで取得できるかどうか。GitHubではConversationタブで確認
> - 「b.行単位の紐づけ(該当行の変更なし)」: レビューコメントが付けられた行とは別の変更を行い、Force pushしたときにレビューコメントの紐づけが残るかどうか。GitHubではFile chagedタブで確認
> - 「c.行単位の紐づけ(該当行の変更あり)」: レビューコメントで付けられた行を修正し、Force pushした時の挙動。レビュー対応をしたとみなしレビューコメントのひも付きは解除されているべきである。GitHubではFile chagedタブで確認
>
> | サービス | a.履歴保持 | b.行単位の紐づけ(該当行の変更なし) | c.行単位の紐づけ(該当行の変更あり) | 備考 |
> |----------------|--------------|---------------------------------|---------------------------------|---------------------------------------------------------------|
> | GitHub | 残る | 残る | 消える | |
> | GitLab | 残る | 残る | 消える | |
> | AWS CodeCommit | 残る | 消える | 消える | Force Push関係なく、最新のコミットに対してのみレビューコメントが紐づく。そのため、新しいコミットをPushすると、過去につけたレビューコメントがファイル詳細から消えたように見える |
::: tip

強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した下表の調査結果においてForce Push運用による支障は無いと言える。

- 「a.履歴保持」: Force Pushを行い、GitHub投稿したレビューコメントが履歴として何かしらのページで取得できるかどうか。GitHubではConversationタブで確認
- 「b.行単位の紐づけ(該当行の変更なし)」: レビューコメントが付けられた行とは別の変更を行い、Force pushしたときにレビューコメントの紐づけが残るかどうか。GitHubではFile chagedタブで確認
- 「c.行単位の紐づけ(該当行の変更あり)」: レビューコメントで付けられた行を修正し、Force pushした時の挙動。レビュー対応をしたとみなしレビューコメントのひも付きは解除されているべきである。GitHubではFile chagedタブで確認

| サービス | a.履歴保持 | b.行単位の紐づけ(該当行の変更なし) | c.行単位の紐づけ(該当行の変更あり) | 備考 |
|----------------|--------------|---------------------------------|---------------------------------|---------------------------------------------------------------|
| GitHub | 残る | 残る | 消える | |
| GitLab | 残る | 残る | 消える | |
| AWS CodeCommit | 残る | 消える | 消える | Force Push関係なく、最新のコミットに対してのみレビューコメントが紐づく。そのため、新しいコミットをPushすると、過去につけたレビューコメントがファイル詳細から消えたように見える |
:::

### 2. メインの開発ブランチに機能ブランチの変更を取り込む

Expand Down
14 changes: 8 additions & 6 deletions documents/forGitBranch/recommended_settings.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,12 +36,14 @@ git config --global alias.ci commit
git config --global alias.br branch
```

> [!NOTE]
> git workflowの補足説明:
>
> - `pull.rebase`: pull時にリベースする
> - `rerere.enabled`: コンフリクトの解決を記録しておき、再び同様のコンフリクトが発生した場合に自動適用する
> - `fetch.prune`: リモートリポジトリで削除されたブランチを削除する
::: tip

git workflowの補足説明:

- `pull.rebase`: pull時にリベースする
- `rerere.enabled`: コンフリクトの解決を記録しておき、再び同様のコンフリクトが発生した場合に自動適用する
- `fetch.prune`: リモートリポジトリで削除されたブランチを削除する
:::

## GitHub推奨設定

Expand Down

0 comments on commit 6432fc8

Please sign in to comment.