From 6432fc811e4881bf062f3a24f1aee10c377cd2bd Mon Sep 17 00:00:00 2001 From: Junki Mano Date: Tue, 23 Jul 2024 13:57:30 +0900 Subject: [PATCH] :::tip (#153) --- ...55\343\203\274\350\246\217\347\264\204.md" | 30 ++++++++++--------- .../forGitBranch/recommended_settings.md | 14 +++++---- 2 files changed, 24 insertions(+), 20 deletions(-) diff --git "a/documents/forGitBranch/Git\343\203\226\343\203\251\343\203\263\343\203\201\343\203\225\343\203\255\343\203\274\350\246\217\347\264\204.md" "b/documents/forGitBranch/Git\343\203\226\343\203\251\343\203\263\343\203\201\343\203\225\343\203\255\343\203\274\350\246\217\347\264\204.md" index 51e64e88..1a4685a9 100644 --- "a/documents/forGitBranch/Git\343\203\226\343\203\251\343\203\263\343\203\201\343\203\225\343\203\255\343\203\274\350\246\217\347\264\204.md" +++ "b/documents/forGitBranch/Git\343\203\226\343\203\251\343\203\263\343\203\201\343\203\225\343\203\255\343\203\274\350\246\217\347\264\204.md" @@ -15,7 +15,7 @@ meta: また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 -# はじめに +## はじめに 本ドキュメントはGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意いただきたい。 @@ -39,7 +39,7 @@ meta: | ---------------- | ------------------------------------------| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- | | GitHub Flow | `main`
| 最小のブランチ管理パターンで、開発人数が少なく、検証作業は全員で行う場合に有効。
マージの都度本番環境へデプロイする前提。 | 低 | ・個人開発
・プロジェクト初期フェーズで断面管理を厳密に行わない場合 | | Lite GitLab Flow | `main`
`develop`
`feature`
`topic`
`hotfix` | GitHub Flowに`develop`ブランチを追加するパターン。（特定の呼称はないのでLite GitLab FLowと命名。）
`main`ブランチをプロダクトリリースブランチとし、開発中ソースコードとは分ける。 | 低 | ・本番リリース済みプロダクトの開発などで、一定品質を保証する必要がある場合
・開発作業とリリース作業が並行しないチーム構成である場合 | -| GitLab Flow | `main`
`develop`
`release`
`feature`
`topic`
`hotfix`z | GitHub Flowに`develop`ブランチと`release`ブランチを追加するパターン。
GitLab Flowでは`main`ブランチを`production`ブランチ、`release`ブランチとを`pre production`ブランチと呼称するが、本規約では`main`/`release`に統一する。 | 中 | ・リリース作業と開発作業が並行して行われる場合
・断面を指定して複数テスト環境にデプロイしたい場合 | +| GitLab Flow | `main`
`develop`
`release`
`feature`
`topic`
`hotfix` | GitHub Flowに`develop`ブランチと`release`ブランチを追加するパターン。
GitLab Flowでは`main`ブランチを`production`ブランチ、`release`ブランチとを`pre production`ブランチと呼称するが、本規約では`main`/`release`に統一する。 | 中 | ・リリース作業と開発作業が並行して行われる場合
・断面を指定して複数テスト環境にデプロイしたい場合 | ### 変則的なパターン @@ -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. メインの開発ブランチに機能ブランチの変更を取り込む diff --git a/documents/forGitBranch/recommended_settings.md b/documents/forGitBranch/recommended_settings.md index de635efd..e1c4e28d 100644 --- a/documents/forGitBranch/recommended_settings.md +++ b/documents/forGitBranch/recommended_settings.md @@ -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推奨設定