Skip to content

Commit

Permalink
embed each_branch
Browse files Browse the repository at this point in the history
  • Loading branch information
@ma91n
ma91n committed Aug 10, 2024
1 parent 462e77f commit 15b515b
Show file tree
Hide file tree
Showing 3 changed files with 107 additions and 102 deletions.
103 changes: 101 additions & 2 deletions documents/forGitBranch/Gitブランチフロー規約.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,9 +23,108 @@ meta:
- トランクベース開発（フィーチャーフラグ）を **採用しない**
- ライブラリではなく、アプリケーション（CLIツール、サーバアプリケーションなど）開発で利用する

# ブランチ戦略の選定
# 基本方針

一般的なGitブランチ運用のプラクティスに従い、本ドキュメントも以下の方針に則る。

- すべての機能開発や不具合修正に、機能ブランチを使用する
- プルリクエストを経由して機能ブランチの修正内容をマージする
- 永続ブランチはデプロイ可能なように整合性を保つ

本ドキュメントで想定する、各ブランチの特徴を説明する。

| ブランチ名称 | 役割 | ライフサイクル | 利用シーン | 命名規則 | 直プッシュ可否 |
| -------------- | ----------------------------------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `main` | production環境と一致させるブランチ | 永続的 | すべてのケースで使用 | `main`: 原則変更しない | ✕ |
| `feature` | 特定機能の追加/変更 | 短命 | すべてのケースで使用 | `feature/${任意名称}`: 詳細はfeatureブランチの章に記載する | △ |
| `develop` | 開発の大元となるブランチ | 永続的 | リリース断面と開発断面を分けたい場合にmainブランチから作成する。<br>マージの都度リリースする前提であればmainブランチとfeatureブランチのみでも運用可能。 | `develop`: 原則変更しない。複数のdevelopブランチが発生した場合は `develop2` と連番で区別する | ✕ |
| `release` | リリース準備作業の実施 | 短命 | developブランチの利用が前提となる。<br>開発作業とリリース作業が並行する場合にdevelopブランチから作成する。 | `release/${yyyymmdd}` や `release/${リリースバージョン}` など | ✕ |
| `hotfix` | mainブランチに対する即時修正 | 短命 | developブランチの利用が前提となる。<br>本番リリースに対して迅速にパッチを当てたい場合にmainブランチから作成する。<br>mainブランチとfeatureブランチのみの運用の場合は必ずしも利用する必要はない。 | `hotfix/${任意名称}`: 可能な限りわかりやすい命名とする | ◯ |
| `topic` | featureブランチにて複数人開発をする場合の開発ブランチ | 短命 | featureブランチで実現する機能を複数人で開発する場合にfeatureブランチから作成する。 | `topic/${任意名称}`: 可能な限りわかりやすい命名とする | ◯ |

## mainブランチ

Gitリポジトリを新規作成するとデフォルトで作成されるブランチで、主な特徴は以下である。

- 過去はmasterだったが最近はmainという名称に改名された
- 個人開発であればmainブランチに直接プッシュして開発することもできるが、チーム開発では直接プッシュ禁止でマージを行うだけのブランチとして扱う
- production環境と対応するブランチとなる場合が多い

## featureブランチ

機能追加や変更を行うブランチで、主な特徴は以下である。

- ひとつの変更に対してひとつのfeatureブランチを作成することになるため、開発中で最も使われる短命なブランチとなる
- mainブランチあるいはdevelopブランチから派生させ、作業完了後に作成元ブランチにマージし、その後削除する
- 後述するtopicブランチを利用しない場合は、基本的に1人の開発者のみが利用する

![feature branch](img/branch_strategy_feature.drawio.png)

以下の命名に従う。

- `feature/` のプレフィックスを付ける
- 課題管理システムと紐付けられるようなブランチ名にする

```sh
# OK（課題管理システムの課題番号をブランチ名に利用）
feature/#12345

# OK（GitHub Issue や JIRA や Backlog のプロジェクトIDをブランチ名に利用）
feature/<PROJECTID>-9403
feature/gh-issue-12345

# NG（プレフィックスが無い）
fixtypo
```

本ドキュメントで想定する各ブランチ役割については[ブランチの整理](each_branch.md)に記載する。
## developブランチ

開発の中心となるブランチで、主な特徴は以下である。

- リポジトリを新規作成した際にmainブランチからdevelopブランチを作成する
- 各開発者はdevelopブランチからfeatureブランチを作成し、機能追加/変更を行う
- 都度リリースをするのであればmainブランチとfeatureブランチのみの運用でも問題ないが、リリース断面と開発断面を分けたい場合にdevelopブランチを利用する
- 体制・開発スケジュールによっては複数のdevelopブランチが発生することもある

![develop branch](img/branch_strategy_develop.drawio.png)

## releaseブランチ

リリースするために使用するブランチで、主な特徴は以下である。

- リリース前の検証を開発と並行して実施する場合に発生する
- 開発とリリース作業が並行しないのであればdevelopブランチでそのまま検証を実施すれば良いので、場合によっては不要となる
- releaseブランチではバグ修正、ドキュメント生成、その他のリリースに伴うタスクのみを実施する
- developブランチからreleaseブランチを作成、リリース準備作業を実施し、mainブランチへマージ後、mainブランチからリリースを行う
- masterブランチのマージコミットにリリースタグ（バージョンなど）を打ち、mainブランチをdevelopブランチへマージ後、releaseブランチを削除する

![release branch](img/branch_strategy_release.drawio.png)

## hotfixブランチ

本番リリースに対して迅速にパッチを当てて修正する場合に使用するブランチで、主な特徴は以下である。

- developブランチではなく、mainブランチをベースとする
- 修正が完了するとmainとdevelopの両方(あるいは進行中のreleaseブランチ)に直ちにマージされ、mainは更新されたバージョン番号でタグ付けされる
- mainブランチとdevelopブランチが分かれている場合はほぼ必須で発生すると考えて良いが、mainブランチ+featureブランチのみの運用では必ずしも必要ではない。（管理上の目的でfeatureとhotfixを分けることはあり得る。）

![hotfix branch](img/branch_strategy_hotfix.drawio.png)

命名はfeatureブランチと同じく、課題管理システムと紐づけるようなブランチ名とする。

## topicブランチ

featureブランチで実現する機能を複数人で開発する場合に使用するブランチで、主な特徴は以下である。

- featureブランチからtopicブランチを作成し、topicブランチ上で個人の開発を行った後、featureブランチへマージする。（masterブランチ/developブランチとfeatureブランチの関係と同等。）
- topicブランチが必要なケースでは、featureブランチへの直接プッシュは原則行わない
- GitHub Flowではfeatureブランチのことをtopicブランチと呼称する場合があるが、本規約ではfeatureブランチから派生するブランチをtopicブランチと定義する

![topic branch](img/branch_strategy_topic.drawio.png)

命名はfeatureブランチと同じく、課題管理システムと紐づけるようなブランチ名とする。

# ブランチ戦略の選定

ブランチ戦略は以下の方針で選定する。

Expand Down
100 changes: 0 additions & 100 deletions documents/forGitBranch/each_branch.md
View file

This file was deleted.

6 changes: 6 additions & 0 deletions documents/forGitBranch/recommended_settings.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,12 @@ Branch protection rules にdevelop, mainなど永続的なブランチに保護
| | Dependabot security updates | ✅️ | |
| | Dependabot version updates | ✅️ | |

## GitLab推奨設定

- GitHubの「Automatically delete head branches」
- マージリクエストから「Delete source branch」オプションを有効にすることが該当
- プロジェクトの設定で「Enable "Delete source branch" option by default」を選択しておくとデフォルトで有効になる

## 設定ファイル

### .gitattribute
Expand Down

0 comments on commit 15b515b

Please sign in to comment.