diff --git a/.vuepress/config.js b/.vuepress/config.js index 0f2e57fa..82ab7e42 100644 --- a/.vuepress/config.js +++ b/.vuepress/config.js @@ -29,6 +29,10 @@ const links = { "/documents/forOpenAPISpecification/OpenAPI_Specification_2.0.html", "/documents/forOpenAPISpecification/OpenAPI_Specification_3.0.3.html", ], + "/documents/forGitBranch/": [ + "/documents/forGitBranch/", + "/documents/forGitBranch/Gitブランチフロー規約.html", + ], }; console.log(links); @@ -133,6 +137,20 @@ module.exports = { }, ], }, + { + text: "Gitブランチフロー規約", + items: [ + { + text: "Home", + link: "/documents/forGitBranch/", + }, + { + text: "Gitブランチフロー規約", + link: "/documents/forGitBranch/Gitブランチフロー規約.html", + }, + + ], + }, ], }, { diff --git a/README.md b/README.md index c4f5cde2..d848e13c 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ features: details: エンタープライズ領域では、社員・パートナーの方々を合わせて、数百人が同時に開発することも珍しくありません。 ちょっとした悩み、失敗も、人数が集まれば大変なコスト・リスクになります。 誰もが引っかかる落とし穴、悩みの種をあらかじめ排除します。 - title: Performance details: 時に読みやすいソースコードはパフォーマンス劣化を招くことがあります。 しかし、常にパフォーマンスを優先したソースコードは人間の読めないソースコードになりがちです。 今、書こうとしているソースコードが、どの程度のパフォーマンスになるのか、指標を示すことで、ソフトウェア開発プロジェクトごとに最適なソースコードを選択することができます。 -footer: ©2015 - 2023 Future Enterprise Coding Standards - Future Corporation +footer: ©2015 - 2024 Future Enterprise Coding Standards - Future Corporation --- [![GitHub last commit](https://img.shields.io/github/last-commit/future-architect/coding-standards.svg)](https://github.com/future-architect/coding-standards) 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" new file mode 100644 index 00000000..878aadcf --- /dev/null +++ "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" @@ -0,0 +1,346 @@ +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 +author: フューチャー株式会社 +meta: + - name: keywords + content: Git +--- + + + +本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 + +ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 + +また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 + +# はじめに + +本ドキュメントはGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意いただきたい。 + +- GitHub または GitLab の利用 +- 開発プロダクトには、ライブラリ（他のアプリケーションやライブラリからimportして利用されるもの）か、アプリケーション（CLIツール、サーバアプリケーションなど）という区別があるが、アプリケーション開発を想定 +- トランクベース開発（フィーチャーフラグ）を **採用しない** + +導入に際して行う、GitやGitHub/GitLabの環境設定は、[推奨設定](recommended_settings.md)ページに記載している。 + +## ブランチ運用パターン + +本ドキュメントで想定する各ブランチ役割については[ブランチの整理](each_branch.md)に記載する。 + +現実的に利用する可能性が高いブランチの運用パターン３つ示す。 + +基本的には運用コストが最小になるパターンを選択し、プロジェクトの体制に応じて運用を変更する。 + +（例） GitHub Flow → Lite GitLab Flow → GitLab Flow + +| 名称 | 利用ブランチ | 概要 | 運用コスト | 使い所 | +| ---------------- | ------------------------------------------| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- | +| 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`に統一する。 | 中 | ・リリース作業と開発作業が並行して行われる場合
・断面を指定して複数テスト環境にデプロイしたい場合 | + +### 変則的なパターン + +#### developブランチが複数作成する場合 + +![multi develop branch](image/branch_strategy_multi_develop.drawio.png) + +複数リリースバージョンを並行して開発する場合、developブランチを複数作るパターンも考えられる。 +上記の例では日々のエンハンスとは別に数カ月後に大型リリースがある場合を想定する。 +あるタイミングで大きく機能が変わる場合にエンハンス用開発ブランチ（`develop`）とは別の開発ブランチ（`develop2`）を作成する。（featureフラグでの対応も考えられるが、本記事でブランチで対応する場合を想定する。） +このパターンではそれぞれのdevelopブランチに対しては独立してfeatureブランチで機能開発が行われるが、`develop`から`develop2`への同期に注意する必要がある。 +`develop`の変更にはバグフィックスや軽微なUI向上が含まれる想定であり、これらの変更は日次あるいは週次の比較的高頻度で本番環境へリリースされる。 +当然、`develop2`はこれらの変更を加味して大型リリース向け開発を進める必要があるので、`develop`のmainブランチ反映されるたびに`develop`から`develop2`への同期を行う必要がある。 +`develop`から`develop2`への同期は以下の様に行う。 + +- rebaseとしてしまうと`develop2`を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットにて同期を行う。 +- 誤操作を避ける目的でcherry-pickは行わない。 + +![release multi develop branch](image/branch_strategy_release_multi_develop.drawio.png) + +develop2のリリースは以下の手順で行う。 + +1. `develop`から`develop2`へマージコミットによって同期を行う。（2でconflictが起こらないよう、前準備の意味合いで実施する。） +2. `develop2`から`develop`にmergeを行い、その後は通常のリリースフローに従う +3. 問題なくリリースが完了し次第、`develop2`を削除する + +`develop`から`develop2`へmerge後、`develop2`を`main`ブランチに反映させる手順も考えられるが、`develop2`から`develop`へのマージとすると以下のメリットがある。 + +- 本番環境（=`develop`）との差分を把握することができる +- より一般的な名称である `develop` ブランチのみ残るため、新規参画者フレンドリーである + +#### 過去バージョンをサポートする場合 + +![multi version branch](image/branch_strategy_multi_version.drawio.png) + +社内ライブラリなど過去のバージョンをサポートする場合、バージョン別にsupportブランチを作成するパターンも考えられる。 +インターフェースの大型改善や、仕様変更を受けてversion1からversion2へupdateを行った場合を想定する。 +メインの更新はversion2（mainブランチ）に対して行っていくが、version1の利用ユーザーが存在する場合、バグfixやセキュリティアップデートを並行して行うことが考えられる。 +そういった場合はversion1を示すブランチ（`support/v1`）を別途作成、そのブランチからfeatureブランチを作成してfixを行う。 +featureブランチのマージ後、マイナーバージョン（あるいはパッチバージョン）を上げたtagをcommitし、本番環境へリリースする。 +※この例ではversion1とversion2が別リソースとして動いていることを前提としている。同一リソースで複数バージョンが稼働する場合はversion2のブランチで対応を行う必要がある。 + +## マージ戦略 + +マージ戦略とは、複数のブランチ間でコードの変更を統合する際に使用される方法やポリシーを指し、以下の事項に影響を与えます。 + +- プロジェクトのコミット履歴の管理 +- コンフリクトの解決 +- 開発プロセスの円滑な進行 +- 最終的なソフトウェア品質 + +そのため、Gitの使用を開始する前に、適切な戦略を策定することが重要である。 + +ブランチの管理戦略に関わらず、大半のケースにおいて、メインの開発ブランチとそこから作成される個々の機能ブランチが存在する。 + +この章では次の2ケースについて、とりうる選択肢と推奨方法を説明する。 + +1. 開発中の機能ブランチに対してメインの開発ブランチの変更をどう取り込むか +2. メインの開発ブランチに開発およびレビューが完了した機能ブランチをどう取り込むか + +### 1. 機能ブランチにメインの開発ブランチの変更を取り込む + +複数人により同時並行的に開発が進む場合、特定の機能ブランチで開発を進めている最中に、メインの開発ブランチがアップデートされることはよく起こる。 + +このような状況において、開発者は自らの機能ブランチに対して、最新の開発ブランチの変更を定期的に取り込むことが望まれる。 + +![開発ブランチと機能ブランチ](image/merge_strategy_develop_to_feature.drawio.png) + +[開発ブランチの変更を機能ブランチに取り込む方法](merge_develop_to_feature.md)に記載している通り、次の2つの方法があり、2の「リベース」による方法を推奨する。 + +1. マージ +2. リベース（★推奨） + +理由は次の通り。 + +- 前提として、別の開発者が行った開発ブランチの変更は、適時機能ブランチに取り込んだテスト実行や動作検証を行うべきである +- 開発ブランチの変更の取り込みをマージで行うと、そのたびにマージコミットが作成され履歴が複雑になるため、レビューアの負荷軽減を目的とする +- リベースによるConflictリスクについては、開発ブランチを取り込む段階でマージ・リベース問わず解消が必要となる + +開発者は `git pull` 時の挙動をリベースにするよう設定する（`git config pull.rebase true`）。 + +マージによる変更の取り込みが既存のブランチを変更しないのに対し、リベースは全く新しい（元のコミットIDとは別のコミットIDで）コミットを作成するため、次の3点に注意すること。 + +1. 複数人に影響を及ぼすpublicなブランチでは、決してリベースを使用しないこと + - 永続ブランチである `develop` や `main` ブランチが該当する + - リベースにより新しいコミットが作成されるため、他の人が作業しているブランチと整合性が取れなくなり、大きな混乱を招く可能性がある。永続ブランチは **強制プッシュできないよう保護しておく** +2. リモートにプッシュ済のブランチでリベースを行った場合、強制プッシュ（Force Push）が必要になること + - 開発者はプッシュ時に `--force-with-lease --force-if-includes` フラグを渡すことで、意図せずリモートブランチの変更を上書きしないようにする + - `--force-with-lease`: ローカルのリモート追跡ブランチの ref とリモートの ref を比較し、ローカルの状態が最新でない場合（要はプッシュ先のリモートブランチに変更が入ったが、ローカルで `git fetch` していない場合）は、プッシュに失敗する。逆にいうと、プッシュ前に `git fetch` を実行済みの場合は、リモートの変更を上書きする形で強制プッシュができてしまうため、これを防ぐには `--force-if-includes` フラグを併用する + - `--force-if-includes`: リモート追跡ブランチの変更がローカルに全て取り込まれていない場合は、プッシュに失敗する。これにより意図せず他の人のコミットを上書きすることを防ぎつつ、必要な変更を強制的にプッシュすることができる +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すると、過去につけたレビューコメントがファイル詳細から消えたように見える | + +### 2. メインの開発ブランチに機能ブランチの変更を取り込む + +プルリクエストを経由して、開発が完了した機能ブランチをメインの開発ブランチに取り込むためには、GitHub（GitLab）上でプルリクエスト（マージリクエスト）を経由する運用を前提とする。 + +[開発ブランチに機能ブランチの変更を取り込む方法](merge_feature_to_develop.md)に記載している通り、次の3パターンの方法があり、3の「Squash and merge」による方法を推奨する。 + +1. Create a merge commit +2. Rebase and merge +3. Squash and merge（★推奨） + +理由は次の通り。 + +- メインの開発ブランチの履歴をクリーンに保てるため +- 機能ブランチのPRが単一のコミットメッセージで表現できるほどシンプルで明確な単位に保ちたいため + +なお、プロテクトブランチの設定にて、メインの開発ブランチに対し「require linear history」を選択することを推奨する。 +本設定を行うと、開発ブランチに対して「Create a merge commit」が選択できないよう制御することができる。 + +また、意図しない方法でのマージを避けるためにブランチごとにマージ戦略を設定しておき、想定外のマージ戦略が選択された時に警告色を表示するとサードパーティ製のChrome拡張も存在する。こちらは必要に応じて導入することが望ましい。 +https://zenn.dev/daku10/articles/github-merge-guardian + +「Squash and merge」による変更の取り込みを行う場合、次の4点に注意すること。 + +1. マージ後は機能ブランチを削除すること + - 変更元の機能ブランチのコミットをまとめたコミットが新たに作成されるめ、元の機能ブランチを再利用して（例えば追加のコミットを作成して）PRを作成してもコンフリクトが発生する。そのためマージ後はリモート/ローカルの双方で速やかに機能ブランチを削除することが望ましい + - リモート側の機能ブランチはGitHubの設定にて「Automatically delete head branches」を選択することで、マージ後に自動でブランチの削除が行われる。（GitLabでは、マージリクエストから「Delete source branch」オプションを有効にすることで、マージ後に自動でブランチの削除が行われる。プロジェクトの設定で「Enable "Delete source branch" option by default」を選択しておくとデフォルトで有効になる。） + - ローカル側の機能ブランチは `branch -d` コマンドでは削除できないため、`branch -D` コマンドを用いて削除する必要がある。 +2. 部分的なコミットの取り消しができない + - 履歴上は1つのコミットになるので、マージ後に一部の変更だけを取り消すということができない。取り消しはPRの単位となるため、PRの単位をなるべく小さなまとまりにすることが望ましい +3. Authorが失われる + - 機能ブランチにコミットを行った人がAuthorになるのではなく、「Squash and merge」を行った人がAuthorになるため、OSS開発を行う場合など、厳密にコントリビューションを管理する必要がある場合は注意されたい。GitHubでは「Squash and merge」を行う場合、デフォルトでコミットメッセージに `co-authored-by` トレーラーが追加され、1つのコミットが複数の作成者に帰属するようにするようになっている[^1]。この記述は削除しないようにする +4. 機能ブランチの取り込み以外のケースでは、「Squash and merge」以外を選択すること + - 例えば、`develop` ブランチを `main` ブランチや `release`ブランチにマージする場合など、取り込み元のブランチの変更が大きい場合は、コミットメッセージを1つにまとめることによる弊害が大きいため、別のマージ戦略を検討すること + +[^1]: https://docs.github.com/ja/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors + +## ブランチ運用アンチパターン + +ブランチ運用でよく課題に上がるパターンとその対応を紹介する。 + +### 追い抜きリリース + +以下のような状況とします。 + +- 2つのチケット（issue-312、issue-394とする）があり、どちらも同じファイルの修正を含む +- 先にissue-312がdevelopにマージされ、その後に着手されたissue-394がマージされた +- 以下のような条件があるため、issue-394分を先にリリースしたい + - issue-312のリリースは業務上の合意が得られていない（エンドユーザ操作に影響があるため、事前告知した日時でリリースしたいなど） + - issue-394は不具合修正であり業務課題として目につくため、なるべく早くリリースして解消したい + +![同一ファイルを複数](image/release_overtaking.drawio.png) + +よく陥りがちな対策としては次の2点が考えられる。 + +1. issue-312をリバートする +2. issue-394のコミットのみをcherry pick してmainブランチにマージする + +1のリバートはGitHubの機能で提供されていることもあり簡単に行えるが、手戻りであることは間違いないし、コミットの履歴が汚れるため、保守運用の視点ではマイナスである。2のcherry pickは操作、管理とも煩雑でミスが出やすいという課題がある。 + +処方箋だが、前提条件に応じて複数の対応策が考えられる。 + +1. issue-312のマージがおかしかったケース + - 本来想定していたリリーススケジュールから見て、issue-312がdevelopにマージされている状態が正しくないのであれば、issue-312はdevelopにマージせず待機しておくべきだった + - 誤ってissue-312をマージしてしまったことが原因であれば、リバートを行うことが正しい +2. issue-394のマージがおかしかったケース + - 本来想定していたリリーススケジュールを破って、issue-394を優先してリリースしたいというのであれば、`feature` ではなく `hotfix` ブランチで対応すべきであった +3. developマージ後、デプロイメント環境へのリリース間隔が数時間~1日など短い場合は、フィーチャーフラグでデプロイとリリースを区別するべきであった + +2の例を以下に図示する + +![hotfixで追い抜き](image/release_overtaking_hotfix.drawio.png) + +## コミットメッセージ + +Gitのコミットメッセージは原則自由とする。理由は以下である。 + +- 通常、作業はチケット管理システムを駆動に開発するため、情報が重複する +- リリースノートの自動生成での扱いは、どちらかといえばラベルとプルリクエストのタイトルが重要 +- メンバーによっては粒度の小さいコミットを好む場合も多く、運用の徹底化を図る負荷が高い + +チーム規模や特性によっては、Gitのコミットメッセージをルール化する方ことにより、メリットがある場合は `Conventional Commits` をベースとした以下の規約を推奨する。 + +- [コミットメッセージ規約](commit_message_rule.md) + +## ブランチ名 + +ブランチ名の命名規則は、[ブランチの整理](each_branch.md)に記載する。 + +## ラベル + +TODO ラベルについて方針を追加する。（ラベルを利用することで、issue, pull requestを分類わけすることができる。適切に設定することでリリースノート作成時に有用である。） + +https://docs.github.com/ja/issues/using-labels-and-milestones-to-track-work/managing-labels + +## タグ + +Gitにはタグ機能があり、リリースポイントとしてタグを作成する運用とする。 + +これにより、リリースしたアプリケーションやライブラリに何か不具合があれば、切り戻しや原因追求が容易になる利点がある。 + +タグの運用ルール: + +- リリースごとに新しいバージョンを示したタグを発行する +- (推奨) GitHubなどの画面経由でタグを作成する +- mainブランチにてタグを作成する +- 入力間違えなどのケースを除き、一度タグをつけた後は削除しない +- 後述する「タグの命名規則」に従う + +![GitHub画面でbackend/v1.6.0のタグを作成する](image/create_new_tag.png) + +何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、以下に注意する。画面経由・コマンドライン経由でのタグ作成は混ぜないようにし、運用手順は統一する。 + +- 軽量 (lightweight) 版ではなく、注釈付き (annotated) 版のタグを利用する + +```sh +# OK（注釈付きタグを利用する） +$ git tag "v1.0.4" -m "v1.0.4 🐛Fix item api log" + +# NG（軽量タグは利用しない） +$ git tag "v1.0.4" +``` + +タグの命名規則: + +- `v1.2.4` などの [セマンティックバージョニング](https://semver.org/lang/ja/) を基本とする +- モノリポの場合は `frontend/v1.0.0`、`backend/v2.0.1` など領域ごとにプレフィックスを付与する形式を取る + - プレフィックスにすることで、タグをリスト表示した場合に視認性を上げることができる + +命名に従うと、次のようなコマンドで絞り込みで表示できる。 + +```sh +$ git tag -l --sort=-version:refname "frontend/v*" +frontend/v2.0.0 +frontend/v1.3.0 +frontend/v1.2.0 +frontend/v1.1.0 +... +``` + +また、Gitクライアントによっては `/` を使うことでフォルダのように階層表示ができるため、プレフィックスの区切り文字は `-` ハイフンではなく、スラッシュとする。 + +``` +![TODO -](VSCodeクライアントで階層表示されている画像.png) +``` + +タグメッセージの規則: + +- (推奨) GitHubを利用中の場合、「[Generate release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)」を用いて、タイトルや本文を自動生成する +- フロントエンド・バックエンドで整合性を保っているのであれば、メモ目的でバージョンを記載する運用を推奨とする +- 実用的な利用用途が思いつかない場合は、開発者視点での楽しみリリースの大きなマイルストーンの名称など、チームの関心事を記入することを推奨とする + +![create new tag](image/create_new_tag_title.png) + +何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、GitHub利用時の規則に合わせて次のように作成する。 + +入力例: + +```sh +# OK +$ git tag -a backend/v1.8.0 -m "backend/v1.8.0" +$ git tag -a backend/v1.9.0 -m "backend/v1.9.0 🚀Release with frontend-v3.0.1" +$ git tag -a backend/v2.0.0 -m "backend/v2.0.0 ✨Android版アプリリリース対応" + +# NG +$ git tag -a backend/v3.0.0 -m "🚀Release version v2.0.0" +``` + +バージョンアップ規則: + +- 開発しているプロダクトがライブラリの場合、セマンティックバージョニングに厳密に従う +- 開発しているプロダクトがシステム（アプリケーション）の場合、その成熟度や初回リリースの区切りでバージョンアップを行うことを推奨する。適切なバージョンアップを行うことで視認性が上がり、運用負荷を下げることができる + - 例1: 初回リリース、カットオーバーで `v1.0.0` に上げる + - 例2: 稼働後1年以上経過し、中規模以上の大きな機能アップデートがあったので、 `v2.0.0` に上げる + +## 参考1:ローカルでの作業例 + +gitコマンドでの作業例を記載する。リモートブランチへのプッシュは、`--force-with-lease --force-if-includes` オプションを付けることを必須とする。 + +```sh +# 変更作業 +git checkout -b +git add +git commit -a + +# リモートブランチの変更を同期 +git pull origin develop + +# コンフリクト対応 +git add ... +git commit -a + +# リモートブランチへプッシュ +git push origin HEAD --force-with-lease --force-if-includes +``` + +## 参考2: VS Code上でのGit操作 + +[VSCode上でのGit操作](vscode_git_ope.md)で、利用頻度が高いとされるGitクライアントである、VS Code上でのGit操作を紹介する。 diff --git a/documents/forGitBranch/README.md b/documents/forGitBranch/README.md index 8c5148c0..5587110d 100644 --- a/documents/forGitBranch/README.md +++ b/documents/forGitBranch/README.md @@ -2,346 +2,22 @@ sidebarDepth: 4 author: フューチャー株式会社 home: true -heroText: Gitブランチ管理標準 -tagline: Future Enterprise Convention Standards for Git Branch +heroText: Gitブランチフロー規約 +tagline: Future Enterprise Standards for Git branch flow pageClass: lang-home footer: ©2015 - 2024 Future Enterprise Coding Standards - Future Corporation --- - +# Resources -本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 +[Gitブランチフローの規約] です。 -ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 +次のリンクから単一ファイルで作成されたコーディング規約を取得できます。 -また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 +- [Markdown](https://github.com/future-architect/coding-standards/blob/master/documents/forGitBranch/Gitブランチフロー規約.md) +- [HTML](https://github.com/future-architect/coding-standards/blob/gh-pages/resources/Gitブランチフロー規約.html) +- [Word](https://github.com/future-architect/coding-standards/raw/gh-pages/resources/Gitブランチフロー規約.docx) -# はじめに +ファイルは[Pandoc]を利用して作成しています。 -本ドキュメントはGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意いただきたい。 - -- GitHub または GitLab の利用 -- 開発プロダクトには、ライブラリ（他のアプリケーションやライブラリからimportして利用されるもの）か、アプリケーション（CLIツール、サーバアプリケーションなど）という区別があるが、アプリケーション開発を想定 -- トランクベース開発（フィーチャーフラグ）を **採用しない** - -導入に際して行う、GitやGitHub/GitLabの環境設定は、[推奨設定](recommended_settings.md)ページに記載している。 - -## ブランチ運用パターン - -本ドキュメントで想定する各ブランチ役割については[ブランチの整理](each_branch.md)に記載する。 - -現実的に利用する可能性が高いブランチの運用パターン３つ示す。 - -基本的には運用コストが最小になるパターンを選択し、プロジェクトの体制に応じて運用を変更する。 - -（例） GitHub Flow → Lite GitLab Flow → GitLab Flow - -|No | 名称 | 永続ブランチ | 短命ブランチ | 概要 | 運用コスト | 使い所 | -|--| ---------------- | ------------------------------------------|--------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- | -|1 | GitHub Flow | `main` | `feature` | 最小のブランチ管理パターンで、開発人数が少なく、検証作業は全員で行う場合に有効。
マージの都度本番環境へデプロイする前提。 | 低 | ・個人開発
・プロジェクト初期フェーズで断面管理を厳密に行わない場合 | -|2 | Lite GitLab Flow | `main`
`develop` | `feature`
`topic`
`hotfix` | GitHub Flowに`develop`ブランチを追加するパターン。（特定の呼称はないのでLite GitLab FLowと命名。）
`main`ブランチをプロダクトリリースブランチとし、開発中ソースコードとは分ける。 | 低 | ・本番リリース済みプロダクトの開発などで、一定品質を保証する必要がある場合
・開発作業とリリース作業が並行しないチーム構成である場合 | -|3 | GitLab Flow | `main`
`develop`
`release`| `feature`
`topic`
`hotfix` | GitHub Flowに`develop`ブランチと`release`ブランチを追加するパターン。
GitLab Flowでは`main`ブランチを`production`ブランチ、`release`ブランチとを`pre production`ブランチと呼称するが、本規約では`main`/`release`に統一する。 | 中 | ・リリース作業と開発作業が並行して行われる場合
・断面を指定して複数テスト環境にデプロイしたい場合 | - -### 変則的なパターン - -#### developブランチが複数作成する場合 - -![multi develop branch](image/branch_strategy_multi_develop.drawio.png) - -複数リリースバージョンを並行して開発する場合、developブランチを複数作るパターンも考えられる。 -上記の例では日々のエンハンスとは別に数カ月後に大型リリースがある場合を想定する。 -あるタイミングで大きく機能が変わる場合にエンハンス用開発ブランチ（`develop`）とは別の開発ブランチ（`develop2`）を作成する。（featureフラグでの対応も考えられるが、本記事でブランチで対応する場合を想定する。） -このパターンではそれぞれのdevelopブランチに対しては独立してfeatureブランチで機能開発が行われるが、`develop`から`develop2`への同期に注意する必要がある。 -`develop`の変更にはバグフィックスや軽微なUI向上が含まれる想定であり、これらの変更は日次あるいは週次の比較的高頻度で本番環境へリリースされる。 -当然、`develop2`はこれらの変更を加味して大型リリース向け開発を進める必要があるので、`develop`のmainブランチ反映されるたびに`develop`から`develop2`への同期を行う必要がある。 -`develop`から`develop2`への同期は以下の様に行う。 - -- rebaseとしてしまうと`develop2`を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットにて同期を行う。 -- 誤操作を避ける目的でcherry-pickは行わない。 - -![release multi develop branch](image/branch_strategy_release_multi_develop.drawio.png) - -develop2のリリースは以下の手順で行う。 - -1. `develop`から`develop2`へマージコミットによって同期を行う。（2でconflictが起こらないよう、前準備の意味合いで実施する。） -2. `develop2`から`develop`にmergeを行い、その後は通常のリリースフローに従う -3. 問題なくリリースが完了し次第、`develop2`を削除する - -`develop`から`develop2`へmerge後、`develop2`を`main`ブランチに反映させる手順も考えられるが、`develop2`から`develop`へのマージとすると以下のメリットがある。 - -- 本番環境（=`develop`）との差分を把握することができる -- より一般的な名称である `develop` ブランチのみ残るため、新規参画者フレンドリーである - -#### 過去バージョンをサポートする場合 - -![multi version branch](image/branch_strategy_multi_version.drawio.png) - -社内ライブラリなど過去のバージョンをサポートする場合、バージョン別にsupportブランチを作成するパターンも考えられる。 -インターフェースの大型改善や、仕様変更を受けてversion1からversion2へupdateを行った場合を想定する。 -メインの更新はversion2（mainブランチ）に対して行っていくが、version1の利用ユーザーが存在する場合、バグfixやセキュリティアップデートを並行して行うことが考えられる。 -そういった場合はversion1を示すブランチ（`support/v1`）を別途作成、そのブランチからfeatureブランチを作成してfixを行う。 -featureブランチのマージ後、マイナーバージョン（あるいはパッチバージョン）を上げたtagをcommitし、本番環境へリリースする。 -※この例ではversion1とversion2が別リソースとして動いていることを前提としている。同一リソースで複数バージョンが稼働する場合はversion2のブランチで対応を行う必要がある。 - -## マージ戦略 - -マージ戦略とは、複数のブランチ間でコードの変更を統合する際に使用される方法やポリシーを指し、以下の事項に影響を与えます。 - -- プロジェクトのコミット履歴の管理 -- コンフリクトの解決 -- 開発プロセスの円滑な進行 -- 最終的なソフトウェア品質 - -そのため、Gitの使用を開始する前に、適切な戦略を策定することが重要である。 - -ブランチの管理戦略に関わらず、大半のケースにおいて、メインの開発ブランチとそこから作成される個々の機能ブランチが存在する。 - -この章では次の2ケースについて、とりうる選択肢と推奨方法を説明する。 - -1. 開発中の機能ブランチに対してメインの開発ブランチの変更をどう取り込むか -2. メインの開発ブランチに開発およびレビューが完了した機能ブランチをどう取り込むか - -### 1. 機能ブランチにメインの開発ブランチの変更を取り込む - -複数人により同時並行的に開発が進む場合、特定の機能ブランチで開発を進めている最中に、メインの開発ブランチがアップデートされることはよく起こる。 - -このような状況において、開発者は自らの機能ブランチに対して、最新の開発ブランチの変更を定期的に取り込むことが望まれる。 - -![開発ブランチと機能ブランチ](image/merge_strategy_develop_to_feature.drawio.png) - -[開発ブランチの変更を機能ブランチに取り込む方法](merge_develop_to_feature.md)に記載している通り、次の2つの方法があり、2の「リベース」による方法を推奨する。 - -1. マージ -2. リベース（★推奨） - -理由は次の通り。 - -- 前提として、別の開発者が行った開発ブランチの変更は、適時機能ブランチに取り込んだテスト実行や動作検証を行うべきである -- 開発ブランチの変更の取り込みをマージで行うと、そのたびにマージコミットが作成され履歴が複雑になるため、レビューアの負荷軽減を目的とする -- リベースによるConflictリスクについては、開発ブランチを取り込む段階でマージ・リベース問わず解消が必要となる - -開発者は `git pull` 時の挙動をリベースにするよう設定する（`git config pull.rebase true`）。 - -マージによる変更の取り込みが既存のブランチを変更しないのに対し、リベースは全く新しい（元のコミットIDとは別のコミットIDで）コミットを作成するため、次の3点に注意すること。 - -1. 複数人に影響を及ぼすpublicなブランチでは、決してリベースを使用しないこと - - 永続ブランチである `develop` や `main` ブランチが該当する - - リベースにより新しいコミットが作成されるため、他の人が作業しているブランチと整合性が取れなくなり、大きな混乱を招く可能性がある。永続ブランチは **強制プッシュできないよう保護しておく** -2. リモートにプッシュ済のブランチでリベースを行った場合、強制プッシュ（Force Push）が必要になること - - 開発者はプッシュ時に `--force-with-lease --force-if-includes` フラグを渡すことで、意図せずリモートブランチの変更を上書きしないようにする - - `--force-with-lease`: ローカルのリモート追跡ブランチの ref とリモートの ref を比較し、ローカルの状態が最新でない場合（要はプッシュ先のリモートブランチに変更が入ったが、ローカルで `git fetch` していない場合）は、プッシュに失敗する。逆にいうと、プッシュ前に `git fetch` を実行済みの場合は、リモートの変更を上書きする形で強制プッシュができてしまうため、これを防ぐには `--force-if-includes` フラグを併用する - - `--force-if-includes`: リモート追跡ブランチの変更がローカルに全て取り込まれていない場合は、プッシュに失敗する。これにより意図せず他の人のコミットを上書きすることを防ぎつつ、必要な変更を強制的にプッシュすることができる -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すると、過去につけたレビューコメントがファイル詳細から消えたように見える | - -### 2. メインの開発ブランチに機能ブランチの変更を取り込む - -プルリクエストを経由して、開発が完了した機能ブランチをメインの開発ブランチに取り込むためには、GitHub（GitLab）上でプルリクエスト（マージリクエスト）を経由する運用を前提とする。 - -[開発ブランチに機能ブランチの変更を取り込む方法](merge_feature_to_develop.md)に記載している通り、次の3パターンの方法があり、3の「Squash and merge」による方法を推奨する。 - -1. Create a merge commit -2. Rebase and merge -3. Squash and merge（★推奨） - -理由は次の通り。 - -- メインの開発ブランチの履歴をクリーンに保てるため -- 機能ブランチのPRが単一のコミットメッセージで表現できるほどシンプルで明確な単位に保ちたいため - -なお、プロテクトブランチの設定にて、メインの開発ブランチに対し「require linear history」を選択することを推奨する。 -本設定を行うと、開発ブランチに対して「Create a merge commit」が選択できないよう制御することができる。 - -また、意図しない方法でのマージを避けるためにブランチごとにマージ戦略を設定しておき、想定外のマージ戦略が選択された時に警告色を表示するとサードパーティ製のChrome拡張も存在する。こちらは必要に応じて導入することが望ましい。 -https://zenn.dev/daku10/articles/github-merge-guardian - -「Squash and merge」による変更の取り込みを行う場合、次の4点に注意すること。 - -1. マージ後は機能ブランチを削除すること - - 変更元の機能ブランチのコミットをまとめたコミットが新たに作成されるめ、元の機能ブランチを再利用して（例えば追加のコミットを作成して）PRを作成してもコンフリクトが発生する。そのためマージ後はリモート/ローカルの双方で速やかに機能ブランチを削除することが望ましい - - リモート側の機能ブランチはGitHubの設定にて「Automatically delete head branches」を選択することで、マージ後に自動でブランチの削除が行われる。（GitLabでは、マージリクエストから「Delete source branch」オプションを有効にすることで、マージ後に自動でブランチの削除が行われる。プロジェクトの設定で「Enable "Delete source branch" option by default」を選択しておくとデフォルトで有効になる。） - - ローカル側の機能ブランチは `branch -d` コマンドでは削除できないため、`branch -D` コマンドを用いて削除する必要がある。 -2. 部分的なコミットの取り消しができない - - 履歴上は1つのコミットになるので、マージ後に一部の変更だけを取り消すということができない。取り消しはPRの単位となるため、PRの単位をなるべく小さなまとまりにすることが望ましい -3. Authorが失われる - - 機能ブランチにコミットを行った人がAuthorになるのではなく、「Squash and merge」を行った人がAuthorになるため、OSS開発を行う場合など、厳密にコントリビューションを管理する必要がある場合は注意されたい。GitHubでは「Squash and merge」を行う場合、デフォルトでコミットメッセージに `co-authored-by` トレーラーが追加され、1つのコミットが複数の作成者に帰属するようにするようになっている[^1]。この記述は削除しないようにする -4. 機能ブランチの取り込み以外のケースでは、「Squash and merge」以外を選択すること - - 例えば、`develop` ブランチを `main` ブランチや `release`ブランチにマージする場合など、取り込み元のブランチの変更が大きい場合は、コミットメッセージを1つにまとめることによる弊害が大きいため、別のマージ戦略を検討すること - -[^1]: https://docs.github.com/ja/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors - -## ブランチ運用アンチパターン - -ブランチ運用でよく課題に上がるパターンとその対応を紹介する。 - -### 追い抜きリリース - -以下のような状況とします。 - -- 2つのチケット（issue-312、issue-394とする）があり、どちらも同じファイルの修正を含む -- 先にissue-312がdevelopにマージされ、その後に着手されたissue-394がマージされた -- 以下のような条件があるため、issue-394分を先にリリースしたい - - issue-312のリリースは業務上の合意が得られていない（エンドユーザ操作に影響があるため、事前告知した日時でリリースしたいなど） - - issue-394は不具合修正であり業務課題として目につくため、なるべく早くリリースして解消したい - -![同一ファイルを複数](image/release_overtaking.drawio.png) - -よく陥りがちな対策としては次の2点が考えられる。 - -1. issue-312をリバートする -2. issue-394のコミットのみをcherry pick してmainブランチにマージする - -1のリバートはGitHubの機能で提供されていることもあり簡単に行えるが、手戻りであることは間違いないし、コミットの履歴が汚れるため、保守運用の視点ではマイナスである。2のcherry pickは操作、管理とも煩雑でミスが出やすいという課題がある。 - -処方箋だが、前提条件に応じて複数の対応策が考えられる。 - -1. issue-312のマージがおかしかったケース - - 本来想定していたリリーススケジュールから見て、issue-312がdevelopにマージされている状態が正しくないのであれば、issue-312はdevelopにマージせず待機しておくべきだった - - 誤ってissue-312をマージしてしまったことが原因であれば、リバートを行うことが正しい -2. issue-394のマージがおかしかったケース - - 本来想定していたリリーススケジュールを破って、issue-394を優先してリリースしたいというのであれば、`feature` ではなく `hotfix` ブランチで対応すべきであった -3. developマージ後、デプロイメント環境へのリリース間隔が数時間~1日など短い場合は、フィーチャーフラグでデプロイとリリースを区別するべきであった - -2の例を以下に図示する - -![hotfixで追い抜き](image/release_overtaking_hotfix.drawio.png) - -## コミットメッセージ - -Gitのコミットメッセージは原則自由とする。理由は以下である。 - -- 通常、作業はチケット管理システムを駆動に開発するため、情報が重複する -- リリースノートの自動生成での扱いは、どちらかといえばラベルとプルリクエストのタイトルが重要 -- メンバーによっては粒度の小さいコミットを好む場合も多く、運用の徹底化を図る負荷が高い - -チーム規模や特性によっては、Gitのコミットメッセージをルール化する方ことにより、メリットがある場合は `Conventional Commits` をベースとした以下の規約を推奨する。 - -- [コミットメッセージ規約](commit_message_rule.md) - -## ブランチ名 - -ブランチ名の命名規則は、[ブランチの整理](each_branch.md)に記載する。 - -## ラベル - -TODO ラベルについて方針を追加する。（ラベルを利用することで、issue, pull requestを分類わけすることができる。適切に設定することでリリースノート作成時に有用である。） - -https://docs.github.com/ja/issues/using-labels-and-milestones-to-track-work/managing-labels - -## タグ - -Gitにはタグ機能があり、リリースポイントとしてタグを作成する運用とする。 - -これにより、リリースしたアプリケーションやライブラリに何か不具合があれば、切り戻しや原因追求が容易になる利点がある。 - -タグの運用ルール: - -- リリースごとに新しいバージョンを示したタグを発行する -- (推奨) GitHubなどの画面経由でタグを作成する -- mainブランチにてタグを作成する -- 入力間違えなどのケースを除き、一度タグをつけた後は削除しない -- 後述する「タグの命名規則」に従う - -![GitHub画面でbackend/v1.6.0のタグを作成する](image/create_new_tag.png) - -何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、以下に注意する。画面経由・コマンドライン経由でのタグ作成は混ぜないようにし、運用手順は統一する。 - -- 軽量 (lightweight) 版ではなく、注釈付き (annotated) 版のタグを利用する - -```sh -# OK（注釈付きタグを利用する） -$ git tag "v1.0.4" -m "v1.0.4 🐛Fix item api log" - -# NG（軽量タグは利用しない） -$ git tag "v1.0.4" -``` - -タグの命名規則: - -- `v1.2.4` などの [セマンティックバージョニング](https://semver.org/lang/ja/) を基本とする -- モノリポの場合は `frontend/v1.0.0`、`backend/v2.0.1` など領域ごとにプレフィックスを付与する形式を取る - - プレフィックスにすることで、タグをリスト表示した場合に視認性を上げることができる - -命名に従うと、次のようなコマンドで絞り込みで表示できる。 - -```sh -$ git tag -l --sort=-version:refname "frontend/v*" -frontend/v2.0.0 -frontend/v1.3.0 -frontend/v1.2.0 -frontend/v1.1.0 -... -``` - -また、Gitクライアントによっては `/` を使うことでフォルダのように階層表示ができるため、プレフィックスの区切り文字は `-` ハイフンではなく、スラッシュとする。 - -``` -![TODO -](VSCodeクライアントで階層表示されている画像.png) -``` - -タグメッセージの規則: - -- (推奨) GitHubを利用中の場合、「[Generate release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)」を用いて、タイトルや本文を自動生成する -- フロントエンド・バックエンドで整合性を保っているのであれば、メモ目的でバージョンを記載する運用を推奨とする -- 実用的な利用用途が思いつかない場合は、開発者視点での楽しみリリースの大きなマイルストーンの名称など、チームの関心事を記入することを推奨とする - -![create new tag](image/create_new_tag_title.png) - -何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、GitHub利用時の規則に合わせて次のように作成する。 - -入力例: - -```sh -# OK -$ git tag -a backend/v1.8.0 -m "backend/v1.8.0" -$ git tag -a backend/v1.9.0 -m "backend/v1.9.0 🚀Release with frontend-v3.0.1" -$ git tag -a backend/v2.0.0 -m "backend/v2.0.0 ✨Android版アプリリリース対応" - -# NG -$ git tag -a backend/v3.0.0 -m "🚀Release version v2.0.0" -``` - -バージョンアップ規則: - -- 開発しているプロダクトがライブラリの場合、セマンティックバージョニングに厳密に従う -- 開発しているプロダクトがシステム（アプリケーション）の場合、その成熟度や初回リリースの区切りでバージョンアップを行うことを推奨する。適切なバージョンアップを行うことで視認性が上がり、運用負荷を下げることができる - - 例1: 初回リリース、カットオーバーで `v1.0.0` に上げる - - 例2: 稼働後1年以上経過し、中規模以上の大きな機能アップデートがあったので、 `v2.0.0` に上げる - -## 参考1:ローカルでの作業例 - -gitコマンドでの作業例を記載する。リモートブランチへのプッシュは、`--force-with-lease --force-if-includes` オプションを付けることを必須とする。 - -```sh -# 変更作業 -git checkout -b -git add -git commit -a - -# リモートブランチの変更を同期 -git pull origin develop - -# コンフリクト対応 -git add ... -git commit -a - -# リモートブランチへプッシュ -git push origin HEAD --force-with-lease --force-if-includes -``` - -## 参考2: VS Code上でのGit操作 - -[VSCode上でのGit操作](vscode_git_ope.md)で、利用頻度が高いとされるGitクライアントである、VS Code上でのGit操作を紹介する。 +[pandoc]: https://pandoc.org/ diff --git a/documents/forGitBranch/commit_message_rule.md b/documents/forGitBranch/commit_message_rule.md index d60f4c8a..178db20c 100644 --- a/documents/forGitBranch/commit_message_rule.md +++ b/documents/forGitBranch/commit_message_rule.md @@ -1,4 +1,10 @@ -# コミットメッセージ規約 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - コミットメッセージ規約 +author: フューチャー株式会社 +--- + +## コミットメッセージ規約 Gitのコミットメッセージにの書式についてルール化することで、コミットの目的がわかりやすくなる、履歴からのトラッキングの容易になる利点がある。 diff --git a/documents/forGitBranch/each_branch.md b/documents/forGitBranch/each_branch.md index 044369fa..b42f2e64 100644 --- a/documents/forGitBranch/each_branch.md +++ b/documents/forGitBranch/each_branch.md @@ -1,4 +1,10 @@ -# ブランチの整理 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - ブランチの整理 +author: フューチャー株式会社 +--- + +## ブランチの整理 本ドキュメントで想定する、各ブランチの特徴を説明する。 diff --git a/documents/forGitBranch/merge_develop_to_feature.md b/documents/forGitBranch/merge_develop_to_feature.md index e8de9a11..7d5b7f75 100644 --- a/documents/forGitBranch/merge_develop_to_feature.md +++ b/documents/forGitBranch/merge_develop_to_feature.md @@ -1,4 +1,10 @@ -# 開発ブランチに機能ブランチの変更を取り込む方法 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - 開発ブランチに機能ブランチの変更を取り込む方法 +author: フューチャー株式会社 +--- + +## 開発ブランチに機能ブランチの変更を取り込む方法 機能ブランチに対して開発ブランチの変更を取り込む方法は「マージ」と「リベース」2つの方法が考えられる。 diff --git a/documents/forGitBranch/merge_feature_to_develop.md b/documents/forGitBranch/merge_feature_to_develop.md index 81b41716..f6c95a81 100644 --- a/documents/forGitBranch/merge_feature_to_develop.md +++ b/documents/forGitBranch/merge_feature_to_develop.md @@ -1,4 +1,10 @@ -# 開発ブランチに機能ブランチの変更を取り込む方法 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - 開発ブランチに機能ブランチの変更を取り込む方法 +author: フューチャー株式会社 +--- + +## 開発ブランチに機能ブランチの変更を取り込む方法 プルリクエストを経由して、開発が完了した機能ブランチをメインの開発ブランチに取り込むためには、GitHub（GitLab）上でプルリクエスト（マージリクエスト）を経由する運用を前提とする。 diff --git a/documents/forGitBranch/recommended_settings.md b/documents/forGitBranch/recommended_settings.md index facb876c..de635efd 100644 --- a/documents/forGitBranch/recommended_settings.md +++ b/documents/forGitBranch/recommended_settings.md @@ -1,4 +1,10 @@ -# 推奨設定 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - 推奨設定 +author: フューチャー株式会社 +--- + +## 推奨設定 GitやGitHubの推奨設定をまとめる。本ドキュメントにあるGitブランチ運用はこの設定が行われている前提で説明する箇所がある。 diff --git a/documents/forGitBranch/vscode_git_ope.md b/documents/forGitBranch/vscode_git_ope.md index 4cddfb12..d36ac305 100644 --- a/documents/forGitBranch/vscode_git_ope.md +++ b/documents/forGitBranch/vscode_git_ope.md @@ -1,4 +1,10 @@ -# VSCode上でのGit操作 +--- +sidebarDepth: 4 +title: Gitブランチフロー規約 - VSCode上でのGit操作 +author: フューチャー株式会社 +--- + +## VSCode上でのGit操作 利用頻度が高いとされるVS CodeでのGit操作を紹介する。 diff --git a/package.json b/package.json index f4c7165e..0ea19de5 100644 --- a/package.json +++ b/package.json @@ -17,7 +17,9 @@ "pandoc:awsresource-html": "pandoc ./documents/forAWSResource/AWSインフラリソース命名規約.md -s --self-contained --number-sections --toc -t html5 -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forAWSResource/AWSインフラリソース命名規約.html", "pandoc:awsresource-word": "pandoc ./documents/forAWSResource/AWSインフラリソース命名規約.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -s -o ./documents/forAWSResource/AWSインフラリソース命名規約.docx", "pandoc:swagger-html": "pandoc ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md -s --self-contained --number-sections --toc -t html5 -F mermaid-filter.cmd -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0規約.html", - "pandoc:swagger-word": "pandoc ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0規約.docx" + "pandoc:swagger-word": "pandoc ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0規約.docx", + "pandoc:gitbranch-html": "pandoc ./documents/forGitBranch/Gitブランチフロー規約.md -s --self-contained --number-sections --toc -t html5 -F mermaid-filter.cmd -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forGitBranch/Gitブランチフロー規約.html", + "pandoc:gitbranch-word": "pandoc ./documents/forGitBranch/Gitブランチフロー規約.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forGitBranch/Gitブランチフロー.docx" }, "repository": { "type": "git ",