私たちは、git-flowによって実装された成功したGit分岐モデルを採用しようとしています。現在、少なくとも2つのリリースブランチに取り組んでいます。1つは最新の安定版リリース用で、もう1つは次の（「プレビュー」）リリース用です。私が理解していないのは、すべてのリリースがマスターに対して「線形化」され、そこでタグ付けされているように見える理由です。リリースブランチでリリースにタグを付けてみませんか？なぜマスターなのか？またはなぜ開発するのかブランチを、マスターを使用しないのですか？
私たちは、git-flowによって実装された成功したGit分岐モデルを採用しようとしています。現在、少なくとも2つのリリースブランチに取り組んでいます。1つは最新の安定版リリース用で、もう1つは次の（「プレビュー」）リリース用です。私が理解していないのは、すべてのリリースがマスターに対して「線形化」され、そこでタグ付けされているように見える理由です。リリースブランチでリリースにタグを付けてみませんか？なぜマスターなのか？またはなぜ開発するのかブランチを、マスターを使用しないのですか？
回答:
git-flowモデルでは、「最新リリース」バージョンは実際にはにマップされmasterますが、「プレビューリリース」はgit-flowreleaseブランチにマップされます。実際のリリースが行わdevelopれるmasterときにフォークされ、最終的にマージされます。その後、これが「最新リリース」になり、通常、git-flowhotfixブランチを使用して、そのリリースのバグのみを修正します。このように、はmaster常に最新リリースバージョンの最も安定した状態を表します。
古いリリースのバグを修正したり、そこで他の開発を行ったりする場合はsupport、適切なコミットからブランチをフォークしmasterます（すべてのバージョンがそこで作成されます）。supportブランチはまだ実験的であり（ドキュメントによると）、十分に文書化されていません。しかし、コマンドラインヘルプからわかるように：
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
これらのブランチは開始されたばかりであり、masterまたはにマージされることを意図していませんdevelop。「古代」のリリースまたは「古代」のリリースで実装するように顧客から要求された機能に対する修正は、に戻れないか、戻らないため、これは通常は問題ありませんmaster。それでも思うなら、あなたがポートに（で表さあなたのメインの開発ラインに修正したいmasterとしdevelop）、ちょうど開始しhotfix、変更内容をチェリーピックと仕上げhotfix。
git flow support実験的とはマークされていません。
枝に少し重点を置きすぎたメンタルモデルのように見えます。同意します。コミットをマスターにマージする代わりに、リリースしたコミットにタグを付けることができます。
でも、絵はきれいです。すべてをマスターにマージすると、バージョンタグがグラフ全体に散らばる代わりに、リリースが時間順に明確に示されます。
ただし、このモデルは古いリリースのバグ修正には機能しないと思います。それはきちんとした順序を台無しにします。
あなたの質問に答えるために：これは、場合によっては単純なメンタルモデルを作る一連のルールだと思います。すべてのルールが純粋に技術的な観点から意味があるわけではありませんが、それが悪いことにはなりません。メンタルモデルは人間にとって良いものです。
supportブランチは古いリリースのバグ修正用に設計されていますが、「実験的」とラベル付けされています。
個人的には、前述のgit-flowは複雑すぎると思います。
GitHubを使用している場合は、 GitHub flow（Scott Chaconの説明に従って）。
これは、複数の機能でのコラボレーション、コードレビューに特に役立ち、次を使用して継続的インテグレーションソリューションと組み合わせることができます。 Commit Status API。
更新：TheGitHubFlow™の新しい公式ウェブサイトがあります
更新2：GitHubFlow™用の新しい公式（および簡略化された）GitHubガイドがあります：https：//guides.github.com/introduction/flow/
master、作品の年表の異常にマージすることはできません。
supportブランチの目的です。しかし、その通りです。そのようなリリースがにマージされないのは確かに異常です。これはmaster、私の理解では、すべての製品リリースを保持する必要があります。
私の場合、基本は同じですが、各バージョンにはいくつかの異なる機能がある同じソフトウェアの2つのバージョンがあります。
つまりworktree、2つ作成します。つまり、マスターの横に2つの関連する長期実行ブランチを作成します。
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
で、〜がある：
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
リポジトリは1つですが、上記のブランチごとに3つの別々のフォルダが並んでいます。そして、マスターで一般的な変更を加えます。次に、それを他の両方のバージョンとマージします。
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
各バージョンの特定の変更も対応するフォルダーに保存され、各プロジェクトの作業は分離され、IDEが混乱することはありません。
お役に立てば幸いです。
@Motに完全に同意します。
同じ質問を聞くのはいいことです。
私たちのチームはまた、Successfulよりも多くのユニバーサルブランチモデルを探していました。つまり、前述の@Motのように、主なアイデアは、リリースをサポートするための追加のリポジトリを導入しないようにすることです。たとえば、安定したリリースのためにkernel.orgによって行われるため、個別の* .gitリポジトリにブランチがあります。しかし、kernel.orgは、ダウンロードされたサイズを最小限に抑えるためにそれを行っています。
私にとっては、開発のメインラインとしてマスターを使用する方がクリーンなようです。
また、リリースにはいくつかの競合があります- *モデルをマスターにマージし、後でアイデアをタグ付けします
マスターでコミットが行われるたびに、Gitフックスクリプトを使用して、ソフトウェアを自動的にビルドし、本番サーバーにロールアウトします
原因の終了（マージとタグ付け）はアトミックトランザクションではありません：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
gitフックが自動バージョン管理サポートを使用してビルドを開始する場合：
$git describe --tags --long >.ver
その場合、誤ったバージョンが次の目的で作成される可能性があります。
$ git merge --no-ff release-1.2
Successl oneでのバージョン管理では、バンプバージョン処理 が導入されることは知っていますが、自動ではありません。
つまり、-リリースのブランチモデルに導入する主な違い-*マージとタグ付けは次のとおりです。-ブランチの作成時にリリースにタグを付ける-リリースのブランチを保持して、将来のメンテナンスを可能にする
マスターブランチは常に本番コードベースを表す必要があるため、本番リリースの直後に常にコードをマスターにマージして戻します。
タグ付けは、製品リリースに組み込まれた正確なコードを「記憶」するために使用されるため、後で戻って、問題が発生した場合にコードを分析できます。
これにより、理論的には、マスターにマージして戻した後、リリースブランチとマスターブランチのどちらでコードにタグを付けるかは重要ではありません。私は個人的にリリースブランチのコードにタグを付けることを好みます。これはまさにビルド/リリースに入ったコードだからです（マージで何かがうまくいかない可能性があると仮定して）。
開発ブランチの概念の問題は、シングルスレッドであるということです。このスレッドのBrendanは、開発ブランチの概念を含む使用可能な戦略について言及しました。