こちらのポストがとても参考になったので、意訳しつつ自分なりに解釈しやすい言葉でまとめ直しました。
https://gist.github.com/digitaljhelms/4287848
メインブランチに寿命はなく、レポジトリには常に stable と master の２つのブランチが存在します。
| Instance | Branch | Description, Instructions, Notes |
|---|---|---|
| Stable | stable | Accepts merges from Working and Hotfixes |
| Working | master | Accepts merges from Features/Issues and Hotfixes |
次のリリースに向けての開発最新版ブランチ。開発時は master からのブランチ作成や master へのマージが主なワークフローとなります。
master は直接編集することはせず、masterから派生したブランチのマージにより更新されます。
本番にデプロイされた最新のコード用ブランチ。日々の開発では、stable ブランチとのやりとりは発生しない。
master ブランチのソースコードが安定版でデプロイされた場合、すべての変更は stable にマージされ、リリース番号をタグ付けします。
サポートブランチは、チームメンバー間の並行開発を支援し、機能の追跡を容易にし、本番での問題を迅速に解決するために使用されます。
メインブランチとは異なり、これらのブランチの寿命は常に限られています。
これらのブランチにはそれぞれ特定の目的があり、ソースブランチとターゲットブランチが明確に定められています。
| Instance | Branch | Format | Source | Target | Description, Instructions, Notes |
|---|---|---|---|---|---|
| Features/Issues | feature bug |
feature-{issue number} bug-{issue number} |
master | master | Always branch off HEAD of Working |
| Hotfix | hotfix | hotfix-{issue number} | stable | stable and master | Always branch off Stable |
feature ブランチは、新機能や機能拡張を開発する場合に使用します。開発を開始するときに、この機能がリリースされるデプロイメントがわからない場合があります。機能ブランチがいつ終了するかにかかわらず、機能ブランチは常に master ブランチにマージされます。
master ブランチへのマージ時に発生し得る競合を処理するコストを減らすために、feature ブランチの開発中に行われた master ブランチへの変更は、随時 feature ブランチへ取り込む（マージする）ようにします。
ブランチがまだ存在しない場合は、ローカルでブランチを作成してから GitHub にプッシュします。
feature ブランチは常に「公開」されていなければなりません。つまり、開発者のローカルブランチだけではなく、リモートにもブランチが存在しなくてはならないということです。
定期的に、master に加えられた変更 (もしあれば) は、feature ブランチにマージされるべきです。
feature ブランチの開発が完了したら、変更を master ブランチにマージし、リモートブランチを削除します。
bug ブランチは feature ブランチとは意味的にのみ異なります。
bug ブランチは、次のデプロイメントにマージすべき不具合の対応を行うために作成されます。そのため、bug ブランチは通常 1 回のデプロイメントサイクルより長くは続かないでしょう。
bug ブランチはバグ修正と機能開発の違いを明確に追跡するために使用されます。bug ブランチはいつ終了するかに関わらず、常にマスターにマージされます。
master ブランチへのマージ時に発生し得る競合を処理するコストを減らすために、bug ブランチの開発中に行われた master ブランチへの変更は、随時 bug ブランチへ取り込む（マージする）ようにします。
ブランチがまだ存在しない場合は、ローカルでブランチを作成してから GitHub にプッシュします。
bug ブランチは常に「公開」されていなければなりません。つまり、開発者のローカルブランチだけではなく、リモートにもブランチが存在しなくてはならないということです。
$ git checkout -b bug-id master // creates a local branch for the new bug
$ git push origin bug-id // makes the new bug remotely available
定期的に、master に加えられた変更 (もしあれば) は bug ブランチにマージされるべきです。
$ git merge master // merges changes from master into bug branch
bug ブランチの開発が完了したら、変更を master ブランチにマージし、リモートブランチを削除します。
$ git switch master // change to the master branch
$ git merge --no-ff bug-id // makes sure to create a commit object during merge
$ git push origin master // push merge changes
$ git push origin :bug-id // deletes the remote branch
本番デプロイされたコードに不具合が見つかり、（予めスケジューリングされた次のデプロイメントを待たずに）すぐに対処する必要がある場合は hotfix ブランチを作成して対応します。
hotfix ブランチは常にタグ付けされた安定版ブランチから分岐します。
緊急性が高いため、まず運用中のバージョンである stable に対し hotfix をマージした後に、修正を次のデプロイメントにも反映させるために master にもマージしておきます。
ブランチがまだ存在しない場合は、ローカルでブランチを作成してから GitHub にプッシュします。
hotfix ブランチは常に「公開」されていなければなりません。つまり、開発者のローカルブランチだけではなく、リモートにもブランチが存在しなくてはならないということです。
$ git checkout -b hotfix-id stable // creates a local branch for the new hotfix
$ git push origin hotfix-id // makes the new hotfix remotely available
hotfix の開発が完了したら、変更を stable にマージしてからタグを更新します。
$ git switch stable // change to the stable branch
$ git merge --no-ff hotfix-id // forces creation of commit object during merge
$ git tag -a <tag> // tags the fix
$ git push origin stable --tags // push tag changes
変更を master にもマージして hotfix を失わないようにし、リモートの hotfix ブランチを削除します。
$ git switch master // change to the master branch
$ git merge --no-ff hotfix-id // forces creation of commit object during merge
$ git push origin master // push merge changes
$ git push origin :hotfix-id // deletes the remote branch