![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-04-25T00:56:40+00:00","default:admin","admin") #author("2023-04-25T01:38:32+00:00","default:admin","admin") -[[【図解】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/]] -ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン -ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる -リモートブランチの名前から、なんのためのブランチかを推測しやすくなる *main / master [#te4e231c] -[[Gitリポジトリのデフォルトブランチの名前が「master」から「main」に変わります:https://backlog.com/ja/product-updates/announcement/change-default-branch-name-from-master-to-main/]] *ブランチの保護 [#k7c77fc0] -[[【Github】勝手にマージされないようにブランチを保護した:https://zakkuri.life/github-protect-branch/]] *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]] ***mainブランチ [#f7dcf29b] -git-flowでは main ブランチに直接コミットすることはなく、マージを行うだけのブランチになる -誤って直接コミットしてしまわないように注意 ***developブランチ [#nab9cfea] -develop ブランチは、開発の中心となるブランチ -開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる -main ブランチ同様、直接このブランチにコミットすることはないので注意 -リポジトリを新規作成したときに、main ブランチから develop ブランチを切っておく ***featureブランチ [#ua2b196a] -feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ -ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる -ブランチの名前は、変更の内容がすぐに分かるような名称にする -develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。 ***releaseブランチ [#u9d7633a] -release ブランチは、その名の通り製品をリリースするために使うブランチ -製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。 -リリース作業が完了したら、main ブランチと develop ブランチにマージして、main ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。 ***hotfixブランチ [#z06aab7c] -製品のリリース後に不具合が見つかった場合は main ブランチから直接 hotfix ブランチを切って緊急の修正を行う -修正完了後に main ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後 hotfix ブランチを削除する -派生元が main になるだけで、操作的には release ブランチと同様 ***supportブランチ（オプション） [#v35ca0e4] -プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる -support ブランチでは、旧バージョンの保守とリリースを行う -サポートが必要なバージョンの main ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う *GitHub Flow [#t1725947] -[[GitHub Flow with GitOpsの導入:https://techblog.zozo.com/entry/github-flow-with-gitops]] -[[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/]] ***mainブランチ [#ee0ac5cf] -現在の製品のメインブランチ -常にデプロイ可能な状態 ***featureブランチ [#s0fba90a] -新しい作業を開始するときに、わかりやすい名前のブランチをmainから分岐 -ローカルでコミットして、同じ名前でリモートにもpush -フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成 -他のメンバーがレビューして確認したら、mainへマージする -mainにマージしたらデプロイできる *GitLab Flow [#h2267557] *トランクベース開発 [#ld2fc611] -[[DevOps 技術: トランクベース開発:https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development?hl=ja%2C]] -[[トランクベース開発について:https://rheb.hatenablog.com/entry/2021/08/24/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%AF%E3%83%99%E3%83%BC%E3%82%B9%E9%96%8B%E7%99%BA%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6]] -[[【DevOps】トランクベース開発導入のための環境整備について:https://note.com/cyberz_cto/n/n64086326c25e]] *フィーチャーフラグ [#hdba8cc7] -[[サイバーエージェントのフィーチャーフラグを活用した高速開発:https://developers.cyberagent.co.jp/blog/archives/35021/]] -[[フィーチャーフラグを活用した高速開発:https://kentakozuka.com/post/%E3%83%95%E3%82%A3%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%95%E3%83%A9%E3%82%AF%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%9F%E9%AB%98%E9%80%9F%E9%96%8B%E7%99%BA/]] *その他 [#rfae5d48] -[[GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します:https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama]]
