- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2022-04-12T05:08:38+00:00","default:admin","admin")
#author("2022-04-14T05:30:38+00:00","default:admin","admin")
*ブランチモデル [#t7072bee]
-[[【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう:https://atmarkit.itmedia.co.jp/ait/articles/1708/01/news015.html]]
-[[Gitのブランチモデル(git-flow, GitHub Flow, GitLab Flow)のブランチ名まとめ:https://www.ninton.co.jp/archives/3304]]
-[[Gitブランチモデルの比較と使い分け:https://yukke722.hatenablog.jp/entry/2020/11/06/084720]]
-[[Gitにおけるブランチ戦略について調べてみた:https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea]]
-[[Gitの運用方法の有名な３パターンについての考察:https://kohei.life/git-flows/https://kohei.life/git-flows/]]
-[[キャスレーの社内開発で利用するgitのブランチモデルとかPull Requestの簡単な解説とか:https://www.casleyconsulting.co.jp/blog/engineer/53/]]
-ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン
-ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる
-リモートブランチの名前から、なんのためのブランチかを推測しやすくなる
**Git-flow [#y8040cce]
-[[Git-flow ～Gitのブランチモデルを知る～:https://tracpath.com/bootcamp/learning_git_git_flow.html]]
-[[Git Flowの推奨はもう止めましょう！:https://itnews.org/news_contents/please-stop-recommending-git-flow]]
***masterブランチ [#nbaaf525]
-git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
-誤って直接コミットしてしまわないように注意
***developブランチ [#nab9cfea]
-develop ブランチは、開発の中心となるブランチ
-開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
-master ブランチ同様、直接このブランチにコミットすることはないので注意
-リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく
***featureブランチ [#ua2b196a]
-feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
-ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
-ブランチの名前は、変更の内容がすぐに分かるような名称にする
-develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。
***releaseブランチ [#u9d7633a]
-release ブランチは、その名の通り製品をリリースするために使うブランチ
-製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
-リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。
***hotfixブランチ [#z06aab7c]
-製品のリリース後に不具合が見つかった場合は master ブランチから直接 hotfix ブランチを切って緊急の修正を行う
-修正完了後に master ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後 hotfix ブランチを削除する
-派生元が master になるだけで、操作的には release ブランチと同様
***supportブランチ（オプション） [#v35ca0e4]
-プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
-support ブランチでは、旧バージョンの保守とリリースを行う
-サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う
**GitHub Flow [#t1725947]
-[[GitHub Flowとは:https://qiita.com/tatane616/items/aec00cdc1b659761cf88]]
-[[【GitHub】GitHub Flowの運用手順について:https://qiita.com/onishi_820/items/c9eb45fa8f40fbd2f149]]
-[[GitHub Flowとは？GitHubを利用した開発フローを覚えよう！:https://tomoyuki65.com/lets-learn-github-flow/]]
***masterブランチ [#ee0ac5cf]
-現在の製品のメインブランチ
-常にデプロイ可能な状態
***featureブランチ [#s0fba90a]
-新しい作業を開始するときに、わかりやすい名前のブランチをmasterから分岐
-ローカルでコミットして、同じ名前でリモートにもpush
-フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
-他のメンバーがレビューして確認したら、masterへマージする
-masterにマージしたらデプロイできる
**GitLab Flow [#h2267557]
**その他 [#rfae5d48]
-[[GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します:https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
