Skip to content

Commit 09a6a2a

Browse files
ma91nma91n
committed
fix note
1 parent 1a0730a commit 09a6a2a

File tree

1 file changed

+35
-31
lines changed

1 file changed

+35
-31
lines changed

‎documents/forGitBranch/git_branch_standards.md‎

Lines changed: 35 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -38,11 +38,11 @@ meta:
3838
| ブランチ名称 | 役割 | ライフサイクル | 派生元ブランチ | 命名規則 | 直プッシュ |
3939
|-----------|-------------------|---------|------------------|---------------------------------------------------|---------|
4040
| `main` | プロダクション環境との同期 | 永続的 | - | `main` 固定 | ❌️ |
41-
| `feature` | 特定機能の追加/変更 | 短命 | `main`／`develop` | `feature/${任意名称}`: 詳細は[featureブランチ](#featureブランチ) を参照 | ✅️※1 |
41+
| `feature` | 特定機能の追加/変更 | 短命 | `main`／`develop` | `feature/${チケット番号}`: 詳細は[featureブランチ](#featureブランチ) を参照 | ✅️※1 |
4242
| `develop` | 開発の大元 | 永続的 | `main` | `develop` 固定。複数必要な場合は `develop2` と連番にする | ❌️ |
4343
| `release` | リリース作業用途 | 短命 | `develop` | `release/${yyyymmdd}` や `release/${リリースバージョン}` など | ❌️ |
44-
| `hotfix` | mainブランチに対する即時修正 | 短命 | `main` | `hotfix/${任意名称}`: featureブランチに準じる | ✅️ |
45-
| `topic` | 複数人での機能開発用と | 短命 | `feature` | `topic/${任意名称}`: featureブランチに準じる | ✅️ |
44+
| `hotfix` | mainブランチに対する即時修正 | 短命 | `main` | `hotfix/${チケット番号}`: featureブランチに準じる | ✅️ |
45+
| `topic` | 複数人での機能開発用と | 短命 | `feature` | `topic/${チケット番号}`: featureブランチに準じる | ✅️ |
4646

4747
※1: topicブランチを利用する場合は、派生させたfeatureブランチへの直プッシュはNGとなる
4848

@@ -132,7 +132,7 @@ featureブランチで実現する機能を複数人で開発する場合に使
132132
|------------------|-------------------------------------------------------------------------|-----------|-----------|--------------------------------------------------------|----|
133133
| GitHub Flow | `main`<br>`feature` | `main` | `main` | ・開発人数がごく限られる場合 | |
134134
| Lite GitLab Flow | `main`<br>`develop`<br>`feature`<br>`topic`<br> `hotfix` | `develop` | `develop` | ・稼働済みのプロダクトなど、品質を保証する必要がある場合 | ※1 |
135-
| GitLab Flow | `main`<br>`develop`<br>`release` <br>`feature`<br>`topic` <br> `hotfix` | `develop` | `release` | ・リリース作業と開発作業が並行して行う必要がる場合<br>・断面を指定して複数テスト環境にデプロイしたい場合 | |
135+
| GitLab Flow | `main`<br>`develop`<br>`release` <br>`feature`<br>`topic` <br> `hotfix` | `develop` | `release` | ・リリース作業と開発作業が並行して行う必要がる場合<br>・断面を指定して複数テスト環境にデプロイしたい場合 | ※2 |
136136

137137
- ※1: 特定の呼称はないためLite GitLab FLowと命名する
138138
- ※2: 本規約では、本来のGitLab Flowの呼称である `production`を`main`、`pre production`を`release`に言い換えている
@@ -143,37 +143,39 @@ featureブランチで実現する機能を複数人で開発する場合に使
143143

144144
| 名称 | 開発環境 | ステージング環境 | プロダクション環境 | 備考 |
145145
|------------------|---------|----------|-----------|----------------------------------------------------------------------------------------------------------------------------------------|
146-
| GitHub Flow | feature | main | main | |
146+
| GitHub Flow | feature | main | main | ・ステージング環境が存在しないことも多い |
147147
| Lite GitLab Flow | feature | develop | main | ・開発環境へはfeatureブランチのPRレビュー後にデプロイする<br>・開発環境へのデプロイ漏れを防ぐため定期的にCI/CDでdevelop断面をリリースすることを推奨する<br>・ステージング環境へはdevelopマージをトリガーにCI/CDでデプロイを推奨する |
148148
| GitLab Flow | develop | release | main | ・開発環境へはdevelopマージをトリガーにCI/CDでデプロイを推奨する<br>・検証期間が長引きそうな場合は、PRレビュー承認後にfeatureブランチから開発環境へのデプロイを許容する |
149149

150150
# ブランチ戦略の拡張
151151

152152
次のような要件があった場合には、ベースとなるブランチ戦略を拡張する必要がある。
153153

154-
1. developブランチが複数作成する場合
154+
1. developブランチを複数作成する場合
155155
2. 過去バージョンをサポートする場合
156156

157-
## 1. developブランチが複数作成する場合
157+
## 1. developブランチを複数作成する場合
158158

159159
![multi develop branch](img/branch_strategy_multi_develop.drawio.png)
160160

161-
複数リリースバージョンを並行して開発する場合、developブランチを複数作るパターンも考えられる。
162-
上記の例では日々のエンハンスとは別に数カ月後に大型リリースがある場合を想定する。
163-
あるタイミングで大きく機能が変わる場合にエンハンス用開発ブランチ（`develop`）とは別の開発ブランチ（`develop2`）を作成する。（featureフラグでの対応も考えられるが、本記事でブランチで対応する場合を想定する。）
164-
このパターンではそれぞれのdevelopブランチに対しては独立してfeatureブランチで機能開発が行われるが、`develop`から`develop2`への同期に注意する必要がある。
165-
`develop`の変更にはバグフィックスや軽微なUI向上が含まれる想定であり、これらの変更は日次あるいは週次の比較的高頻度でプロダクション環境へリリースされる。
166-
当然、`develop2`はこれらの変更を加味して大型リリース向け開発を進める必要があるので、`develop`のmainブランチ反映されるたびに`develop`から`develop2`への同期を行う必要がある。
167-
`develop`から`develop2`への同期は以下の様に行う。
161+
日々のエンハンス開発と並行して、数カ月後に大型リリースを行いたい場合がある。このときは複数リリースバージョンを並行して開発するため、 `develop`、`develop2` といった複数の開発ブランチを作る必要がある。
168162

169-
- リベースとしてしまうと`develop2`を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットにて同期を行う。
170-
- 誤操作を避ける目的でcherry-pickは行わない。
163+
概要:
164+
165+
- `develop` の変更にはバグフィックスや軽微なUI向上が含まれ、日次／週次などの頻度でプロダクション環境へリリースされる
166+
- `develop2` は`develop` ブランチの変更をすべて取り込んだ上で、大型機能の準備を行う必要がある
167+
168+
`develop2` 同期の注意点:
169+
170+
- リベースすると `develop2` を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットをお用いる
171+
- 誤操作を避ける目的でcherry-pickは行わない
172+
- `devleop2` への同期は、 `develop` -> `main` ブランチに反映されるタイミングで同期を行う（これにより、品質保証済みの変更のみ取り入れることができる９
171173

172174
![release multi develop branch](img/branch_strategy_release_multi_develop.drawio.png)
173175

174-
develop2のリリースは以下の手順で行う。
176+
### develop2のリリース手順
175177

176-
1. `develop`から`develop2`へマージコミットによって同期を行う。（2でコンフリクトが起こらないよう、前準備の意味合いで実施する。）
178+
1. `develop`から`develop2`へマージコミットする（2でコンフリクトが起こらないよう、前準備の意味合いで実施する。）
177179
2. `develop2`から`develop`にマージを行い、その後は通常のリリースフローに従う
178180
3. 問題なくリリースが完了し次第、`develop2`を削除する
179181

@@ -186,18 +188,20 @@ develop2のリリースは以下の手順で行う。
186188

187189
![multi version branch](img/branch_strategy_multi_version.drawio.png)
188190

189-
社内ライブラリなど過去のバージョンをサポートする場合、バージョン別にsupportブランチを作成するパターンも考えられる。
190-
インターフェースの大型改善や、仕様変更を受けてversion1からversion2へupdateを行った場合を想定する。
191-
メインの更新はversion2（mainブランチ）に対して行っていくが、version1の利用ユーザーが存在する場合、バグfixやセキュリティアップデートを並行して行うことが考えられる。
192-
そういった場合はversion1を示すブランチ（`support/v1`）を別途作成、そのブランチからfeatureブランチを作成してfixを行う。
193-
featureブランチのマージ後、マイナーバージョン（あるいはパッチバージョン）を上げたタグをコミットし、プロダクション環境へリリースする。
194-
※この例ではversion1とversion2が別リソースとして動いていることを前提としている。同一リソースで複数バージョンが稼働する場合はversion2のブランチで対応を行う必要がある。
191+
（社内外の）ライブラリでインターフェースの大型改善や仕様変更を受けて、メジャーバージョンを1→2に上げることがる。この時に過去バージョンもサポートする必要があると、バージョン別にsupportブランチを作成する。
192+
193+
概要:
194+
195+
- メインの更新はversion2（mainブランチ）に対して行っていくが、version1の利用ユーザーが存在する場合、バグfixやセキュリティアップデートを並行して行う
196+
- version1を示すブランチ（`support/v1`）を別途作成、そのブランチからfeatureブランチを作成する
197+
- featureブランチのマージ後、マイナーバージョン（あるいはパッチバージョン）を上げたタグをコミットし、リリースする
198+
- ※この例ではversion1とversion2が別リソースとして動いていることを前提としている。同一リソースで複数バージョンが稼働する場合はversion2のブランチで対応を行う必要がある。
195199

196200
# マージ戦略の選定
197201

198202
マージ戦略とは、複数のブランチ間で生じた変更の取り込み方針を指す。
199203

200-
具体的には次の3ケースそれぞれで「マージコミット」「リベース」「スカッシュマージ」のどれを採用するか判断する。
204+
具体的には次の3ケースそれぞれで、「マージコミット」「リベース」「スカッシュマージ」のどれを採用するか判断する。
201205

202206
1. 開発ブランチから機能ブランチへ変更を取り込む
203207
2. 機能ブランチから開発ブランチへ変更を取り込む
@@ -235,13 +239,13 @@ featureブランチのマージ後、マイナーバージョン（あるいは
235239
- `--force-with-lease`: ローカルのリモート追跡ブランチの ref とリモートの ref を比較し、ローカルの状態が最新でない場合（プッシュ先のリモートブランチに変更が入ったが、ローカルで `git fetch` していない場合）は、プッシュに失敗する。逆にいうと、プッシュ前に `git fetch` を実行済みの場合は、リモートの変更を上書きする形で強制プッシュができてしまうため、これを防ぐには `--force-if-includes` フラグを併用する
236240
- `--force-if-includes`: リモート追跡ブランチの変更がローカルに全て取り込まれていない場合は、プッシュに失敗する。これにより意図せず他の人のコミットを上書きすることを防ぎつつ、必要な変更を強制的にプッシュすることができる
237241

238-
::: tip
242+
::: tip 強制プッシュでレビューコメントは消えるのか？
239243

240-
強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した調査結果では強制プッシュ運用による支障はなかった。
244+
強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した調査結果では問題なかった。
241245

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

246250
| サービス | a.履歴保持 | b.行単位の紐づけ（該当行の変更なし） | c.行単位の紐づけ（該当行の変更あり） |
247251
|----------------|--------------|---------------------------------|---------------------------------|
@@ -493,7 +497,7 @@ git config --global alias.br branch
493497

494498
- プライベートリポジトリ
495499
- Organization配下に作成
496-
- Teamsプラン以上の有料契約
500+
- Teamsプラン以上の有料契約（※プロテクトブランチの機能などを利用するために必要）
497501

498502
### General
499503

0 commit comments

Comments
 (0)