Github - フロー関連の変更点 - .NET 開発基盤部会 Wiki

追加された行はこの色です。
削除された行はこの色です。
Github - フロー関連へ行く。
Github - フロー関連の差分を削除
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>Githubの使い方]]

*目次 [#of8fd8f5]
#contents

*概要 [#h9abe1dc]
採用するフローは、CONTRIBUTING.mdに記載しておくと良い。

https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/CONTRIBUTING.md


*詳細 [#k22a9453]
以下、AIにGit Flow と GitHub Flow の概要と違いを概説していただいた（笑）

**Git Flow [#hbec09ac]
-Vincent Driessen によって考案されたブランチ戦略
-主に長期運用するプロジェクト や リリース管理が重要な開発で採用

***特徴 [#abaf15a5]
-複数のブランチを活用する戦略
-リリース単位での開発を重視
-本番環境と開発環境を明確に分離

***ブランチ構成 [#s6fa6956]
-main（master）ブランチ~
安定版（リリース済みのコード）のみ

-develop ブランチ~
開発用のメインブランチ

-feature ブランチ
--新機能開発用のブランチ
--`develop` から作成し、完了後に `develop` にマージ

-release ブランチ
--リリース準備用のブランチ
--`develop` から作成し、最終調整後 `main` にマージ

-hotfix ブランチ
--本番環境でのバグ修正用
--`main` から作成し、修正後 `main` と `develop` にマージ

***適用シーン [#z101d174]
-エンタープライズ向けアプリケーション**（長期運用を考慮）
-リリース管理が厳密なソフトウェア**
-複数人チームでの開発

**GitHub Flow [#o2526434]
-GitHub に最適化された シンプルなブランチ戦略
-継続的デリバリー（CD）を前提とした開発に適す。

***特徴 [#k3abc507]
-main（master）ブランチを常にデプロイ可能な状態にする**
-基本的に1つのブランチ（main）を中心に開発**
-リリースのたびに main に直接マージ**
-シンプルなフローで高速開発向き**

***ブランチ構成 [#e55bcb6a]
-main（master）ブランチ~
デプロイ可能な最新のコード

-feature ブランチ（トピックブランチ）
--新機能やバグ修正用の一時的なブランチ
--`main` から作成し、完了後 `main` にマージして削除

***フロー [#g223fb82]
+`main` から `feature` ブランチを作成
+コード変更後、GitHub でプルリクエスト（PR）を作成
+レビュー後 `main` にマージ
+本番環境にデプロイ

***適用シーン [#r7863d4d]
-Webアプリやマイクロサービス（頻繁なリリースが必要）
-アジャイル開発
-スタートアップや小規模チーム

***比較表 [#m4fa7492]
||Git Flow|GitHub Flow|h
|開発スタイル| リリース単位の開発|継続的デリバリー（CD）|
|ブランチ数|多い（main, develop, feature, release, hotfix）|少ない（main, feature）|
|リリース管理|明確なリリースサイクル|即時リリース|
|適用プロジェクト | 長期運用、大規模開発|Webサービス、小規模開発|
|メリット|安定性が高い、リリース管理しやすい|シンプル、迅速な開発が可能|
|デメリット|運用が複雑|リリース管理が難しい|

***選択基準 [#e2ded1f4]
-Git Flow~
大規模プロジェクト（エンタープライズ向け、厳密なリリース管理が必要）  

-GitHub Flow~
小規模プロジェクト（Webアプリ開発、アジャイル開発）  

GitHub Flow のシンプルさを活かしつつ、必要に応じて Git Flow の要素を取り入れると良い。

例えば、OpenTouryoProjectでは、main（master）、develop、featureで運用していたりシた。

*参考 [#ec98da3c]
-git flowとgithub flowとは？その違いは？ - Qiita~
https://qiita.com/mint__/items/bfc58589b5b1e0a1856a

**GitHub Flow [#y75cbab2]
-GitHub Flow - Scott Chacon（原文）~
http://scottchacon.com/2011/08/31/github-flow.html
-GitHub Flow (Japanese translation)（上記記事の日本語訳）~
https://gist.github.com/Gab-km/3705015

**git-flow [#ped33d2c]
-A successful Git branching model » nvie.com~
http://nvie.com/posts/a-successful-git-branching-model/
-見えないチカラ A successful Git branching model を翻訳しました~
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
Github - フロー関連 の変更点

Github - フロー関連の変更点
