From 2312599660fd50cb8b5da75a7e88dd42ca00b739 Mon Sep 17 00:00:00 2001 From: ota-meshi Date: Mon, 23 Dec 2024 17:21:52 +0900 Subject: [PATCH] chore: update workflow --- .github/workflows/GHPages.yml | 2 - .github/workflows/test-pandoc-resources.yml | 12 ++++ .../forGitBranch/git_branch_standards.md | 64 +++++++++---------- 3 files changed, 44 insertions(+), 34 deletions(-) diff --git a/.github/workflows/GHPages.yml b/.github/workflows/GHPages.yml index 236fb16b..fddec337 100644 --- a/.github/workflows/GHPages.yml +++ b/.github/workflows/GHPages.yml @@ -40,8 +40,6 @@ jobs: - uses: docker://pandoc/latex:2.9 with: args: "pandoc ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -s -o ./public/resources/OpenAPI_Specification_2.0.docx" - - name: Copy img directory - run: cp -r ./documents/forGitBranch/img ./img - uses: docker://pandoc/latex:2.9 with: args: "pandoc ./documents/forGitBranch/git_branch_standards.md -s --self-contained --number-sections --toc -t html5 -c ./documents/common/pandoc_styles/css/style.css -o ./public/resources/Gitブランチフロー.html" diff --git a/.github/workflows/test-pandoc-resources.yml b/.github/workflows/test-pandoc-resources.yml index 93732cf0..83a8f838 100644 --- a/.github/workflows/test-pandoc-resources.yml +++ b/.github/workflows/test-pandoc-resources.yml @@ -44,6 +44,18 @@ jobs: - uses: docker://pandoc/latex:2.9 with: args: "pandoc ./documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -s -o ./public/resources/OpenAPI_Specification_2.0.docx" + - uses: docker://pandoc/latex:2.9 + with: + args: "pandoc ./documents/forGitBranch/git_branch_standards.md -s --self-contained --number-sections --toc -t html5 -c ./documents/common/pandoc_styles/css/style.css -o ./public/resources/Gitブランチフロー.html" + - uses: docker://pandoc/latex:2.9 + with: + args: "pandoc ./documents/forGitBranch/git_branch_standards.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -s -o ./public/resources/Gitブランチフロー.docx" + - uses: docker://pandoc/latex:2.9 + with: + args: "pandoc ./documents/forSlack/slack_usage_guidelines.md -s --self-contained --number-sections --toc -t html5 -c ./documents/common/pandoc_styles/css/style.css -o ./public/resources/Slack利用ガイドライン.html" + - uses: docker://pandoc/latex:2.9 + with: + args: "pandoc ./documents/forSlack/slack_usage_guidelines.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -s -o ./public/resources/Slack利用ガイドライン.docx" - name: Archive resources uses: actions/upload-artifact@v4 with: diff --git a/documents/forGitBranch/git_branch_standards.md b/documents/forGitBranch/git_branch_standards.md index 2e1860ae..00835d12 100644 --- a/documents/forGitBranch/git_branch_standards.md +++ b/documents/forGitBranch/git_branch_standards.md @@ -70,7 +70,7 @@ Gitリポジトリを新規作成するとデフォルトで作成されるブ - ひとつの変更に対してひとつのfeatureブランチを作成し、作業完了後に削除するため、開発中で最も使われる短命なブランチである - 基本的に1人の開発者のみが利用する -![feature branch](img/branch_strategy_feature.drawio.png) +![feature branch](./img/branch_strategy_feature.drawio.png) 以下の命名に従う。 @@ -92,7 +92,7 @@ fixtypo 開発の中心となるブランチである。 -![develop branch](img/branch_strategy_develop.drawio.png) +![develop branch](./img/branch_strategy_develop.drawio.png) ## releaseブランチ @@ -102,7 +102,7 @@ fixtypo - releaseブランチではバグ修正、ドキュメント生成、その他のリリースに伴うタスクのみを実施する - masterブランチのマージコミットにリリースタグを打ち、mainブランチをdevelopブランチへマージ後、releaseブランチを削除する -![release branch](img/branch_strategy_release.drawio.png) +![release branch](./img/branch_strategy_release.drawio.png) ## hotfixブランチ @@ -111,7 +111,7 @@ fixtypo - 修正が完了するとmainとdevelopの両方(あるいは進行中のreleaseブランチ)にマージされる - main／developブランチがあると必要になる可能性がある。main／featureブランチのみの運用では必須ではない（管理上の目的でfeatureとhotfixを分けることはあり得る） -![hotfix branch](img/branch_strategy_hotfix.drawio.png) +![hotfix branch](./img/branch_strategy_hotfix.drawio.png) ## topicブランチ @@ -120,7 +120,7 @@ featureブランチで実現する機能を複数人で開発する場合に使 - topicブランチが必要なケースでは、featureブランチへの直接プッシュを行ってはならない - GitHub Flowではfeatureブランチのことをtopicブランチと呼称する場合があるが、本規約ではfeatureブランチから派生するブランチをtopicブランチと定義する -![topic branch](img/branch_strategy_topic.drawio.png) +![topic branch](./img/branch_strategy_topic.drawio.png) # ブランチ戦略の選定 @@ -163,7 +163,7 @@ featureブランチで実現する機能を複数人で開発する場合に使 ## 1. developブランチを複数作成する場合 -![multi develop branch](img/branch_strategy_multi_develop.drawio.png) +![multi develop branch](./img/branch_strategy_multi_develop.drawio.png) 日々のエンハンス開発と並行して、数カ月後に大型リリースを行いたい場合がある。このときは複数リリースバージョンを並行して開発するため、 `develop`、`develop2` といった複数のdevelopブランチを作る必要がある。 @@ -178,7 +178,7 @@ featureブランチで実現する機能を複数人で開発する場合に使 - 誤操作を避ける目的でcherry-pickは行わない - `devleop2` への同期は、 `develop` -> `main` ブランチに反映されるタイミングで同期を行う（これにより、品質保証済みの変更のみ取り入れることができる９ -![release multi develop branch](img/branch_strategy_release_multi_develop.drawio.png) +![release multi develop branch](./img/branch_strategy_release_multi_develop.drawio.png) ### develop2のリリース手順 @@ -193,7 +193,7 @@ featureブランチで実現する機能を複数人で開発する場合に使 ## 2. 過去バージョンをサポートする場合 -![multi version branch](img/branch_strategy_multi_version.drawio.png) +![multi version branch](./img/branch_strategy_multi_version.drawio.png) （社内外の）ライブラリでインターフェースの大型改善や仕様変更を受けて、メジャーバージョンを1→2に上げることがる。この時に過去バージョンもサポートする必要があると、バージョン別にsupportブランチを作成する。 @@ -230,7 +230,7 @@ developブランチの変更をfeatureブランチに取り込む方法には、 | 1. マージコミット | 2. リベース | | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| ![マージ](img/merge_strategy_develop_to_feature_merge.drawio.png) | ![リベース](img/merge_strategy_develop_to_feature_rebase.drawio.png) | +| ![マージ](./img/merge_strategy_develop_to_feature_merge.drawio.png) | ![リベース](./img/merge_strategy_develop_to_feature_rebase.drawio.png) | | `get fetch & git merge`（≒ `git pull`）。マージコミットが作成される | `get fetch & git rebase`（≒ `git pull --rebase`）。最新の開発ブランチの先頭から新たにコミットを作りなされ、マージコミットは作成されない | 本規約の推奨は「2. リベース」である。 @@ -325,12 +325,12 @@ Terraformはplanが成功しても、applyが失敗することは多々あり developブランチにfeatureブランチの変更を取り込む方法は下表のように3パターン存在する。 -| | 1.マージコミット | 2.リベース | 3.スカッシュマージ | -| ---- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -| 名称 | Create a merge commit | Rebase and merge | Squash and merge | -| 流れ | ![Merge Commit](img/merge_strategy_feature_to_develop_merge_commit.drawio.png) | ![Rebase and Merge](img/merge_strategy_feature_to_develop_rebase_and_merge.drawio.png) | ![Squash and Merge](img/merge_strategy_feature_to_develop_squash_and_merge.drawio.png) | -| 説明 | `git merge --no-ff` で変更を取り込む | featureブランチを最新のdevelopブランチにリベースし、`git merge --ff` で変更を取り込む | `git merge --squash` で変更を取り込む | -| 特徴 | developブランチにマージコミットが作成される | マージコミットは作成されず、履歴が一直線になる | featureブランチで行った変更YとZを1つにまとめたコミットがdevelopブランチに作成される | +| | 1.マージコミット | 2.リベース | 3.スカッシュマージ | +| ---- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | +| 名称 | Create a merge commit | Rebase and merge | Squash and merge | +| 流れ | ![Merge Commit](./img/merge_strategy_feature_to_develop_merge_commit.drawio.png) | ![Rebase and Merge](./img/merge_strategy_feature_to_develop_rebase_and_merge.drawio.png) | ![Squash and Merge](./img/merge_strategy_feature_to_develop_squash_and_merge.drawio.png) | +| 説明 | `git merge --no-ff` で変更を取り込む | featureブランチを最新のdevelopブランチにリベースし、`git merge --ff` で変更を取り込む | `git merge --squash` で変更を取り込む | +| 特徴 | developブランチにマージコミットが作成される | マージコミットは作成されず、履歴が一直線になる | featureブランチで行った変更YとZを1つにまとめたコミットがdevelopブランチに作成される | ::: tip GitLabを利用する場合 @@ -338,11 +338,11 @@ GitLabでも開発ブランチに機能ブランチの変更を取り込む方 ただし、マージリクエスト上のオプションによってコミット履歴が変わる点が注意である。 -| | 1. Merge commit | 2. Merge commit with semi-linear history | 3. Fast-forward merge | -| ---- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -| 流れ | ![Merge commit with squash commits](img/merge_strategy_feature_to_develop_squash_and_merge_gitlab.drawio.png) | 省略 | 省略 | -| 説明 | GitHubにおける `Create a merge commit` と同様のマージ方法 | `Merge commit` と同じコマンドを使用して、機能ブランチの変更を取り込む方法 | GitHubにおける `Rebase and merge` と同様のマージ方法 | -| 注意 | `Squash commits` を選択してマージした場合、`squash commit` と `merge commit` の2つのコミットが作成される | ソースブランチがターゲットブランチより古い場合はリベースしないとマージできない。 | マージリクエスト上で `Squash commits` を選択してマージした場合、GitHubにおける `Squash and merge` と同様のマージ方法になる（※補足1） | +| | 1. Merge commit | 2. Merge commit with semi-linear history | 3. Fast-forward merge | +| ---- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | +| 流れ | ![Merge commit with squash commits](./img/merge_strategy_feature_to_develop_squash_and_merge_gitlab.drawio.png) | 省略 | 省略 | +| 説明 | GitHubにおける `Create a merge commit` と同様のマージ方法 | `Merge commit` と同じコマンドを使用して、機能ブランチの変更を取り込む方法 | GitHubにおける `Rebase and merge` と同様のマージ方法 | +| 注意 | `Squash commits` を選択してマージした場合、`squash commit` と `merge commit` の2つのコミットが作成される | ソースブランチがターゲットブランチより古い場合はリベースしないとマージできない。 | マージリクエスト上で `Squash commits` を選択してマージした場合、GitHubにおける `Squash and merge` と同様のマージ方法になる（※補足1） | （※補足1）マージ方法で Merge commit を選択して、マージリクエスト上で Squash commits オプションを選択してマージした場合は以下と同義である @@ -418,7 +418,7 @@ git merge --no-ff $SOURCE_SHA - issue-312のリリースは業務上の合意が得られていない（エンドユーザ操作に影響があるため、事前告知した日時でリリースしたいなど） - issue-394は不具合修正であり業務上の優先度が高いため、なるべく早くリリースしたい -![同一ファイルを複数](img/release_overtaking.drawio.png) +![同一ファイルを複数](./img/release_overtaking.drawio.png) よく陥りがちな対策としては次の2点が考えられる。 @@ -437,7 +437,7 @@ git merge --no-ff $SOURCE_SHA 2の例を以下に図示する -![hotfixで追い抜き](img/release_overtaking_hotfix.drawio.png) +![hotfixで追い抜き](./img/release_overtaking_hotfix.drawio.png) # ブランチ命名規則 @@ -457,7 +457,7 @@ Gitにはタグ機能があり、リリースポイントとしてタグを作 - 入力間違えなどのケースを除き、一度タグをつけた後は削除しない - 後述する「タグの命名規則」に従う -![GitHub画面でbackend/v1.6.0のタグを作成する](img/create_new_tag.png) +![GitHub画面でbackend/v1.6.0のタグを作成する](./img/create_new_tag.png) 何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、以下に注意する。画面経由・コマンドライン経由でのタグ作成は混ぜないようにし、運用手順は統一する。 @@ -496,7 +496,7 @@ frontend/v1.1.0 - フロントエンド・バックエンドで整合性を保っているのであれば、メモ目的でバージョンを記載する運用を推奨とする - 実用的な利用用途が思いつかない場合は、開発者視点での楽しみリリースの大きなマイルストーンの名称など、チームの関心事を記入することを推奨とする -![create new tag](img/create_new_tag_title.png) +![create new tag](./img/create_new_tag_title.png) 何かしらの理由で、コマンドラインからタグを作成する必要がある場合は、GitHub利用時の規則に合わせて次のように作成する。 @@ -869,7 +869,7 @@ GUIでのGit操作にあたり、次の2つの拡張機能をインストール サイドバー > Explorer か Source Control > Clone Repository ボタンをクリックし、URLを入力すると、リポジトリをクローンできる。 -![Clone1](img/vscode_git_clone1.png) ![Clone2](img/vscode_git_clone2.png) +![Clone1](./img/vscode_git_clone1.png) ![Clone2](./img/vscode_git_clone2.png) ### コミットグラフの表示 @@ -877,7 +877,7 @@ SOURCE CONTROL パネル > 黒丸のグラフアイコン (View Git Graph (git l 白丸のグラフアイコン (Show Commit Graph) はGitLensのコミットグラフだが、冒頭の記述通り、Pro版でのみの提供となる。 -![Graph1](img/vscode_git_graph1.png) ![Graph2](img/vscode_git_graph2.png) +![Graph1](./img/vscode_git_graph1.png) ![Graph2](./img/vscode_git_graph2.png) ### リモートのフェッチ／プル (`git fetch` / `git pull`) @@ -886,11 +886,11 @@ SOURCE CONTROL パネル > 黒丸のグラフアイコン (View Git Graph (git l - SOURCE CONTROL パネル > 三点リーダーアイコン (More Actions...) をクリックし、 Fetch を選択 - コミットグラフ > 雲アイコン (Fetch from Remote(s)) をクリック -![Fetch1](img/vscode_git_fetch1.png) +![Fetch1](./img/vscode_git_fetch1.png) なお、フェッチ後に以下のようなダイアログが表示される場合があるが、 "Yes" を選択すると、自動で定期的にフェッチを行う。 -![Fetch2](img/vscode_git_fetch2.png) +![Fetch2](./img/vscode_git_fetch2.png) ### ブランチの作成／チェックアウト (`git branch` / `git checkout`) @@ -902,17 +902,17 @@ SOURCE CONTROL パネル > 黒丸のグラフアイコン (View Git Graph (git l - コミットグラフ > 作成元コミットの行上で右クリックし、Create Branch... を選択 - "Check out" にチェックを入れると、作成したブランチにチェックアウトする -![Branch1](img/vscode_git_branch1.png) ![Branch2](img/vscode_git_branch2.png) +![Branch1](./img/vscode_git_branch1.png) ![Branch2](./img/vscode_git_branch2.png) ### ステージ／コミット／プッシュ (`git add` / `git commit` / `git push`) SOURCE CONTROL パネル > 変更ファイルの行 > +アイコン (Stage Changes) をクリックすると、対象ファイルをステージできる。（Changes > +アイコン (Stage All Changes) をクリックすると、すべての変更をステージする） -![Stage](img/vscode_git_stage.png) +![Stage](./img/vscode_git_stage.png) 必要な変更をステージ後、 SOURCE CONTROL パネル内でコミットメッセージを入力し、 Commit ボタンをクリックすると、コミットを作成できる。 -![Commit](img/vscode_git_commit.png) +![Commit](./img/vscode_git_commit.png) 以下のいずれかの操作を実行すると、作成したコミットをリモートリポジトリにプッシュできる。 @@ -920,6 +920,6 @@ SOURCE CONTROL パネル > 変更ファイルの行 > +アイコン (Stage Chang - BRANCHES パネル > 対象ブランチの行 > 雲アイコン (Publish Branch) をクリック - コミットグラフ > 対象ブランチの上で右クリックし、Push Branch... を選択 -![push1](img/vscode_git_push1.png) ![push2](img/vscode_git_push2.png) ![push3](img/vscode_git_push3.png) +![push1](./img/vscode_git_push1.png) ![push2](./img/vscode_git_push2.png) ![push3](./img/vscode_git_push3.png) :::