GitHub の Issues(タスク管理)や Projects(プロジェクト管理)を利用した運用方法を、Git ワークフローに当てはめながら解説いたします。
素の Git によるソース管理の運用方法やワークフローについては以前の記事で解説いたしました。
では、Git のホスティングサービスである GitHub を利用した場合の運用方法やその手順はどのような感じになるでしょうか。
GitHub を利用するメリットは、環境構築のしやすさやブラウザ画面上からの操作で運用が視覚的にわかりやすいことですね。
特に Git 標準にはないプルリクエストの機能は、今やソース管理の運用上かかせないものであり、GitHub(もしくはその他の Git プラットフォーム)を使わない選択肢はほとんどなくなってきているのではないでしょうか。
また、Issues や Projects という機能により、単なるソース管理という枠を超えてかなり充実したサービスとなっています。
これらの機能を利用しながら、Git ワークフローの実際の運用手順について説明したいと思います。
GitHub の環境構築の手順については、以下の記事を参考にしてください。
参考: GitHub の環境構築から git clone までの手順
プロジェクトの作成
ユーザアイコンのメニューより Your profile を選択します。
![GitHub your profile GitHub your profile](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_01.png)
上部タブの Projects を選択し、「New project」をクリックします。
![GitHub New project GitHub New project](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_02.png)
プロジェクト作成のウィンドウが表示され、4つのテンプレートの選択が出てきます。
![GitHub 4つのテンプレート GitHub 4つのテンプレート](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_03b.png)
ここでは Board を選択します。
ボードレイアウトはカンバン方式(ジャストインタイム方式)による issue 管理を実現します。
タスクアイテムの追加も容易で、アイテムの移動もマウス操作で簡単にできます。
Board を選択すると、以下のようなプロジェクト画面が表示されます。
![GitHub プロジェクト画面 GitHub プロジェクト画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_04a.png)
Todo、In Progress、Done の3つのステータスのカラムが作られていますね。
カンバン方式で扱う各工程がこのカラムにあたります。
カラムは「+」をクリックすることで簡単に追加できます。
また、カラム名をシングルクリックすることですぐにカラム名の変更ができます。
これでプロジェクトが作成できました。
![GitHub プロジェクト一覧 GitHub プロジェクト一覧](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_06.png)
ちなみに Team backlog のテンプレートだともう少し詳しい工程に割り振られます。
![GitHub Team backlog GitHub Team backlog](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_05-1024x122.png)
リポジトリとプロジェクトの関連付け
リポジトリとプロジェクトを関連付けします。
リポジトリのトップページの上部タブ Projects をクリックします。
![GitHub リポジトリ画面 GitHub リポジトリ画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_07.png)
右上の「Add project」をクリックし、該当するプロジェクトを選択します。
複数のプロジェクトが該当する場合は複数選択します。
![GitHub プロジェクト追加 GitHub プロジェクト追加](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_08.png)
リポジトリとプロジェクトが関連付けされました。
これでリポジトリのトップ画面からもプロジェクトの画面にいけるようになりました。
![GitHub リポジトリとプロジェクトの関連付け GitHub リポジトリとプロジェクトの関連付け](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_09-1024x238.png)
プロジェクトの設定
プロジェクト画面の右上「…」のアイコンをクリックするとメニューが現れますので、Settings を選択します。
![GitHub プロジェクトの設定 GitHub プロジェクトの設定](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a01.png)
・Project settings
プロジェクト名や README、public/private などを設定できます。
プロジェクトの削除・クローズもここでできます。
![GitHub Project settings GitHub Project settings](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a02-1024x662.png)
・Manage access
プロジェクトメンバー(コラボレータ)の招待やアクセス権(Read/Write/Admin)が設定できます。
![GitHub Manage access GitHub Manage access](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a03.png)
Read
チームや個人はプロジェクトを参照することしかできません。
Write
チームや個人はプロジェクトを参照・編集できます。
Admin
チームや個人はプロジェクトを参照・編集でき、新しいコラボレータを追加できます。
・Custom fields
プロジェクト画面に表示されるフィールドを設定します。
デフォルトで Status というフィールドが存在し、ボードレイアウトのカラムに対応しています。
Status フィールドの設定もここからできますが、ボードレイアウトから行う方が良いかと思います。
![GitHub Custom fields GitHub Custom fields](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a04.png)
新しくフィールドを作成するには、左メニュー「+New field」をクリックし、フィールド名と種類を選択して「Save」ボタンをクリックします。
![GitHub カスタムフィールドの作成 GitHub カスタムフィールドの作成](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a05.png)
作成したフィールドは、テーブルレイアウトやボードレイアウトのカラムとして表示されます。
ここでは優先度というフィールドを作成してみました。
テーブルレイアウトでは以下のように表示されます。
この画面の「+」でもフィールドの追加はできるようです。
![GitHub テーブルレイアウトのフィールド表示 GitHub テーブルレイアウトのフィールド表示](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a06.png)
ボードレイアウトではこのように表示されます。
![GitHub テーブルレイアウトのフィールドの表示 GitHub ボードレイアウトのフィールドの表示](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a07.png)
フィールドの設定はそのままにして、表示/非表示だけ変えることも可能です。
先ほどの Settings の画面からプロジェクト画面に戻り、View 1 タブのプルダウンをクリックして、レイアウトメニューを出します。
![GitHub プロジェクト画面の表示設定 GitHub プロジェクト画面の表示設定](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a08.png)
Table / Board の表示切り替えもここでできますね。
fields の行をクリックすると表示設定が出てきます。
表示したいものを Hidden fields から選択、非表示にしたいものを Visible fields から選択します。
![GitHub フィールドの表示設定 GitHub フィールドの表示設定](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_a09.png)
ワークフロー
issue の作成から本番リリースまでの手順を、Git ワークフローにあてはめながら説明します。
例としてはいまいちですが、使っていくとこんな感じになります。
![GitHub プロジェクト画面ボードレイアウト全体 GitHub プロジェクト画面ボードレイアウト全体](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b01-1024x434.png)
ちなみにこの例ではテンプレートからいくつかのカスタマイズを行っています。
・レビュー待ち(In Review)と保留(On Hold)のカラム追加
・ラベルと優先度(独自に作成)のフィールド表示
1. タスクの発生(No Status → Todo)
不具合を修正したい、新機能を追加したいなど、なんらかのタスクが発生したら、Todo カラムにアイテムを作成します。
Todo カラム下部の「+Add item」をクリックすると入力欄がでてきますので、タイトルを入力します。
![GitHub タスクアイテムの作成 GitHub タスクアイテムの作成](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b02.png)
タスクアイテムが作成されました。
![GitHub 新規タスクアイテム GitHub 新規タスクアイテム](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b03.png)
作成したアイテムを issue 化します。
アイテムにマウスを置くと「…」が現れますのでこれをクリックし、「Convert to issue」をクリックします。
リポジトリが複数ある場合はリポジトリ選択のウィンドウが出てきますので、該当するリポジトリを選択します。
![GitHub タスクアイテムの issue 化 GitHub タスクアイテムの issue 化](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b04.png)
タスクアイテムが issue 化され、リポジトリと紐づきました。
![GitHub タスクアイテムと issue およびリポジトリの紐づけ GitHub タスクアイテムと issue およびリポジトリの紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b06.png)
もちろん issue を作成してからプロジェクトに紐づけることもできます。
リポジトリトップ画面の上部タブ issues をクリックします。
![GitHub リポジトリ画面 issue タブ GitHub リポジトリ画面 issue タブ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b09.png)
右上の「New issue」をクリックします。
![GitHub issue 一覧画面 GitHub issue 一覧画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b10.png)
issue のタイトルやコメントを入力し、右側メニューの Projects の歯車をクリックして issue をプロジェクトに紐づけます。
![GitHub issue 入力画面 GitHub issue 入力画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b11.png)
「Submit new issue」をクリックして保存します。
Project の Status が No status になっているので、Todo に変更します。
Status: No status をクリックすると選択メニューが現れます。
![GitHub issue 画面からのプロジェクトステータスの変更 GitHub issue 画面からのプロジェクトステータスの変更](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b12.png)
プロジェクト画面に戻ると issue が Todo カラムの中にタスクアイテムとして追加されていますね。
![GitHub issue 画面からのタスクアイテム追加 GitHub issue 画面からのタスクアイテム追加](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b13.png)
タスクアイテムのタイトルをクリックすると編集画面が出てきます。
右側メニューにはアサインする人、ラベル、マイルストン、Status、自身で作成したフィールド(ここでは優先度)の設定ができるようになっています。
![GitHub タスクアイテムの編集画面 GitHub タスクアイテムの編集画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b15.png)
下図はラベルの選択画面です。
![GitHub タスクアイテム編集画面のラベル選択 GitHub タスクアイテム編集画面のラベル選択](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b16.png)
ラベルや優先度も設定すると、各アイテムはこんな感じに表示されるようになりました。
![GitHub プロジェクト画面ボードレイアウト GitHub プロジェクト画面ボードレイアウト](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_b17.png)
2. タスクのアサイン(Todo → In Progress)
issue に対して担当者を割り振ります。
タスクアイテムのタイトルをクリックして issue 編集画面を開きます。
右側メニュー Assignees の「Add assignees…」をクリックすると、メンバーの選択画面がでてきますので、アサインするメンバーを選択します。
![GitHub 担当者のアサイン GitHub 担当者のアサイン](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_c01.png)
アサインされた担当者はタスクアイテムを In Progress に移動させ、実際の作業を開始します。
![GitHub タスクアイテムの移動 GitHub タスクアイテムの移動](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_c02-1024x501.png)
ワークフロー:手順 ①
① ローカルのdevelop
ブランチを作成(すでに作成済みであれば最新の状態に)し、これを元に作業ブランチを作成。
# ローカルのdevelopブランチの作成
>git checkout develop
Switched to a new branch 'develop'
Branch develop set up to track remote branch develop from origin.
# ローカルのdevelopブランチを最新の状態に
>git pull origin develop
From https://github.com/yanox2/TestRep
* branch develop -> FETCH_HEAD
Already up to date.
# git checkout -b [作成ブランチ名] [派生元ブランチ名]
>git checkout -b feature/issue02 develop
Switched to a new branch 'issue02'
3. プルリクエスト(In Progress → In Review)
修正が完了したら作業ブランチをコミットし、リモートにあげます。
ワークフロー:手順 ②③
② 修正をcommit
する。
>git add -A
>git commit -m "不具合の修正"
[feature/issue02 d523861] 不具合の修正
1 file changed, 3 insertions(+)
create mode 100644 sample.php
③ 作業ブランチをリモートにあげる。
>git push origin feature/issue02:feature/issue02
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 322 bytes | 322.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'feature/issue02' on GitHub by visiting:
remote: https://github.com/yanox2/TestRep/pull/new/feature/issue02
remote:
To https://github.com/yanox2/TestRep.git
* [new branch] feature/issue02 -> feature/issue02
作業ブランチをリモートにあげると、リポジトリトップ画面にプルリクエストのボタンがでてきます。
![GitHub プルリクエストの作成 GitHub プルリクエストの作成](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d01.png)
「Compare & pull request」をクリックすると、当該ブランチに対応したプルリクエスト画面がでてきます。
base: をdevelop
に変更し、compare: を当該作業ブランチ(feature/issue02
)に変更します。
(この手順の場合、compare: はすでに当該作業ブランチが選択された状態になっています)
コメントを入力して「Create pull request」をクリックします。
これでプルリクエストが作成されました。
![GitHub プルリクエストの作成2 GitHub プルリクエストの作成2](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d02.png)
通常のプルリクエスト画面からの場合は、リポジトリトップ画面の上部タブ Pull requests をクリックします。
「New pull request」をクリックしてプルリクエスト作成画面へいきます。
![GitHub プルリクエスト画面 GitHub プルリクエスト画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d03.png)
base: をdevelop
に、compare: をfeature/issue02
に変更します。
![GitHub プルリクエスト画面ブランチの選択 GitHub プルリクエスト画面ブランチの選択](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d04.png)
「Create pull request」をクリックすると、先ほどのプルリクエスト作成画面までたどりつけます。
![GitHub プルリクエストの作成 GitHub プルリクエストの作成](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d04a.png)
作成されたプルリクエストの画面です。
右側メニューでレビュアーやラベル等を設定できます。
![GitHub 作成されたプルリクエストの画面 GitHub 作成されたプルリクエストの画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d05.png)
ブランチの設定(Settings → Branches)が Require approvals の場合、プルリクエストの画面は以下のようになり、承認されないとマージできなくなります。
![承認が必要なプルリクエスト画面 承認が必要なプルリクエスト画面](https://softwarenote.info/wp-content/uploads/2022/10/fig3658_d05b.png)
次にプルリクエストと issue を紐づけます。
右側メニュー Development の歯車をクリックすると issue の一覧がでてきますので、該当するものにクリックします。
![GitHub プルリクエストと issue の紐づけ GitHub プルリクエストと issue の紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d06.png)
これでプルリクエストと issue が紐づきました。
![GitHub プルリクエストと issue の紐づけ GitHub プルリクエストと issue の紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d06b.png)
issue 画面を確認してみましょう。
一覧から当該 issue へ行き、右側メニューの Development が以下のようになっていれば紐づけがうまくできています。
![GitHub issue とプルリクエストの紐づけ GitHub issue とプルリクエストの紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d06c.png)
もしうまく紐づいていないようであれば、歯車をクリックするとリポジトリおよびブランチの一覧がでてきますので、該当するものを選択して「Apply」ボタンをクリックします。
![GitHub issue とプルリクエストの紐づけ GitHub issue とプルリクエストの紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d07.png)
プロジェクト画面に戻り、当該アイテムのタイトルをクリックして編集画面を見てみましょう。
![GitHub タスクアイテムとプルリクエストの紐づけ GitHub タスクアイテムとプルリクエストの紐づけ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d08.png)
プルリクエストへのリンクができています。
これでタスクアイテムとプルリクエストと issue が紐づきました。
最後に当該アイテムを In Review に移動させます。
![GitHub タスクアイテムの移動 GitHub タスクアイテムの移動](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d09.png)
4. プルリクエストの承認(In Review → Done)
リクエストを確認し、問題がなければプルリクエストを承認します。
プルリクエスト一覧の画面より該当するプルリクエストを選択します。
上部メニューの Files changed をクリックし、修正内容を確認します。
![プルリクエスト画面(File changed) プルリクエスト画面(File changed)](https://softwarenote.info/wp-content/uploads/2022/10/fig3658_e01a.png)
コメントを追加するコード行にカーソルを合わせ、青いコメント アイコンをクリックします。
複数行にコメントを追加するには、クリックしてドラッグして行の範囲を選択し、青いコメント アイコンをクリックします。
![](https://softwarenote.info/wp-content/uploads/2022/10/hover-comment-icon-1024x465.gif)
レビューが完了したら「Review changes」をクリックし、レビュー結果を入力します。
![プルリクエストの承認 プルリクエストの承認](https://softwarenote.info/wp-content/uploads/2022/10/fig3658_e01b-1.png)
レビュー結果には以下の3種類があります。
Comment
一旦コメントのみ追加しました(承認はしていない)。
当該開発者への質問や議論が必要な場合にはこれを選択します。
この後、いくつかやり取りが行われてから承認という流れになります。
Approve
プルリクエストを承認します。
ソースコードの内容に問題がない場合はこれを選択します。
Request changes
プルリクエストを承認するには修正が必要です。
このままでは承認できないと判断した場合はこれを選択します。
プルリクエストが承認されると、マージができるようになります。
![GitHub プリリクエスト画面 GitHub プリリクエスト画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e01.png)
「Merge pull request」をクリックすると作業ブランチがリモートのdevelop
ブランチにマージされます。
なお、マージに関しては3つの選択肢があります。
![GitHub マージの種類 GitHub マージの種類](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e02.png)
Create a merge commit
マージコミットを作成してマージします。
fast-forward させない--no-ff
オプションを指定したマージです。
本サイトではこれを推奨します(デフォルトもこれです)。
>git merge --no-ff feature/issue02
Squash and merge
マージコミットが作成されますが、コミットがまとめられて元のコミットの情報がなくなります。
Rebase and merge
マージの際に fast-forward が行われます。
ログはきれいになりますが、マージの取り消しが難しくなります。
Create a merge commit の場合、コメント入力を入力し、「Confirm merge」をクリックします。
![GitHub マージコミット GitHub マージコミット](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e03.png)
マージが完了し、プルリクエストはクローズされました。
![GitHub プルリクエストの承認 GitHub プルリクエストの承認](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e04.png)
作業ブランチはリモートのdevelop
ブランチにマージされました。
![GitHub 作業ブランチのマージ GitHub 作業ブランチのマージ](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e05.png)
リモートにあげた作業ブランチは必要なくなったので削除します。
ブランチを切り替えるプルダウンをクリックし、View all branches をクリックします。
![GitHub ブランチ一覧の表示 GitHub ブランチ一覧の表示](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e06.png)
削除するブランチのごみ箱アイコンをクリックします。
![GitHub 作業ブランチの削除 GitHub 作業ブランチの削除](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e07.png)
これでリモートの作業ブランチは削除できました。
ちなみにプルリクエストが承認されたと同時に自動的にブランチの削除を自動で行うこともできます。
リポジトリトップ画面の Settings をクリックし、下図の項目にチェックを入れます。
![GitHub マージされたブランチの自動削除 GitHub マージされたブランチの自動削除](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e08.png)
ただし、develop
ブランチをmain
ブランチにマージしたときなど、思わぬブランチが削除される可能性がありますのでこの設定はお勧めではありません。
最後にアイテムを Done に移動させて終了です。
![GitHub タスクアイテムの移動 GitHub タスクアイテムの移動](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_e09-1024x219.png)
とりあえずこれで個々の issue 的には完了ですが、全体としては修正の本番リリース(デプロイ)を行う必要があります。
5. 本番リリース(デプロイ)
通常ではdevelop
ブランチへのマージはステージング環境に繋げているはずなので、個々にマージされた修正をステージング環境にて正常動作するかテストを行います。
テストで問題がなければdevelop
ブランチをmain
ブランチへマージ、すなわち本番環境へのデプロイを行います。
基本的には本番リリースの権限を持つ人は、限られた人数の専任者であるべきです。
したがってデプロイ(すなわちmain
ブランチへのマージ)においては、専任者へプルリクエストを行い承認を得るという運用ルールがあった方が良いかと思います。
リポジトリトップ画面の上部タブ Pull requests をクリックし、「New pull request」をクリックしてプルリクエスト作成画面へいきます。
![GitHub プルリクエスト画面 GitHub プルリクエスト画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_d03.png)
base: をmain
に、compare: をdevelop
に変更します。
![GitHub プルリクエスト作成画面 GitHub プルリクエスト作成画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f01.png)
develop
ブランチの履歴やソースコードの差分を確認し、「Create pull request」をクリックします。
![GitHub プルリクエスト入力画面 GitHub プルリクエスト入力画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f02.png)
コメントを入力して「Create pull request」でプルリクエストは完了です。
右側メニューでレビュアー(専任者)やラベルを設定できます。
![GitHub プルリクエスト画面 GitHub プルリクエスト画面](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f03.png)
プロジェクトとリンクさせればプロジェクト画面のカラムに表示されます。
![GitHub プルリクエストアイテムの表示 GitHub プルリクエストアイテムの表示](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f04.png)
専任者はこのアイテムをクリックすることでプルリクエスト画面に飛ぶことができます。
プルリクエストの承認は 4. の手順と同じです。
承認が完了したら、develop
ブランチがmain
ブランチにマージされ、本番リリースが行われます。
![GitHub プルリクエストの承認 GitHub プルリクエストの承認](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f05-1024x242.png)
このアイテムはプルリクエストが承認されたと同時に自動的に Done に移動します。
これは Workflows にそのような設定がされているからです。
プロジェクト画面の右上「…」のアイコンをクリックするとメニューが現れますので Workflows を選択します。
![GitHub Workflows の設定 GitHub Workflows の設定](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f06.png)
デフォルトではアイテムが close したときのフローと、プルリクエストがマージされたときのフローが設定されています。
![GitHub デフォルトの Workflows の設定 GitHub デフォルトの Workflows の設定](https://softwarenote.info/wp-content/uploads/2022/09/fig3658_f07.png)
以上が一通りの流れとなります。
参考: GitHub の環境構築から git clone までの手順
参考: GitHub Actions を利用した本番環境適用(デプロイ)の方法
参考: Git ワークフロー(ブランチモデル)とその手順
コメント