web-dev-qa-db-ja.com

複数の並列リリースブランチを備えたGitフローとマスター

Git-flowで実装されている 成功したGit分岐モデル を採用しようとしています。現在、少なくとも2つのリリースブランチに取り組んでいます。1つは最新の安定版リリース用で、もう1つは次の（「プレビュー」）リリース用です。私が理解できないのは、すべてのリリースがmasterに対して「線形化」され、そこでタグ付けされているように見える理由です。リリースブランチでリリースにタグを付けないのはなぜですか？なぜmasterなのか？または、なぜdevelopブランチで、masterを使用しないのですか？

gitgit-flow
73
Mot

Git-flowモデルでは、「最新リリース」バージョンは実際にmasterにマッピングされますが、「プレビューリリース」はgit-flow releaseブランチにマッピングされます。これはdevelopから分岐され、実際のリリースが発生したときに最終的にmasterにマージされます。これが「最新リリース」になり、通常はgit-flow hotfixbranchesを使用して、そのリリースのバグのみを修正します。このようにして、masterは常に最新リリースバージョンの最も安定した状態を表します。

古いリリースのバグを修正したり、他の開発をしたい場合は、supportの適切なコミットからmasterブランチをフォークします（そこに作成されたすべてのバージョン）。 supportブランチはまだ実験的であり（ ドキュメントによると ）、十分に文書化されていません。しかし、コマンドラインヘルプからわかるように：

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

これらのブランチは開始されたばかりであり、masterやdevelopにマージすることを意図していません。これは通常、「古代」リリースへの修正または「古代」リリースで実装するように顧客から要求された機能に対する修正は、masterに戻れないか、またはすべきではないためです。まだ考えている場合は、メインの開発ライン（masterおよびdevelopで表される）に修正を移植し、hotfixを開始して変更をチェリーピックし、 hotfixを終了します。

66
mstrap

主にメンタルモデルのように見えますが、ブランチを強調しすぎています。私は同意します。マスターに戻すのではなく、リリースしたコミットにタグを付けることができます。

しかし、写真はきれいです。すべてをマスターにマージすると、バージョンタグがグラフ全体に散らばるのではなく、リリースが時間順に明確に示されます。

しかし、このモデルは古いリリースのバグ修正には機能しないと思います。それはきちんとした順序を台無しにします。

  1. バージョン1.0.1以降の機能を追加し、1.1.0をリリースしたとします。
  2. 1.0.1でバグを発見し、両方のバージョンで修正したい
  3. Masterで1.1.0の後に1.0.2を追加し、1.1.1を直接（またはその前に）推測する必要があります。

あなたの質問に答えるために：これは、場合によっては単純なメンタルモデルを作成する一連のルールだと思います。すべてのルールが純粋に技術的な観点から意味をなすわけではありませんが、それが悪いことではありません。メンタルモデルは人間にとって良いものです。

8
Sarien

個人的には、前述のgit-flowは複雑すぎると思います。

GitHubを使用している場合は、 GitHub flow （Scott Chaconによる説明）。

複数の機能のコラボレーション、コードレビューに特に役立ちます。 Commit Status API 。

[〜＃〜] update [〜＃〜]：新しい GitHub Flow™の公式Webサイト

更新2：GitHub Flow™の新しい公式（および簡略化された）GitHubガイドがあります： https：//guides.github。 com/introduction/flow /

3
Haralan Dobrev

@Motに完全に同意します。

同じ質問を聞いてうれしいです。

また、チームは Successfull oneよりも多くのユニバーサル分岐モデルを探していました。つまり上記の@Motのように-主なアイデアは、例えばrelease。*ブランチを個別の* .gitリポジトリでサポートするための余分なリポジトリを導入しないようにすることです。これは、例えば安定版リリース用のkernel.orgによって行われます。しかし、kernel.orgは、ダウンロードしたサイズを最小限に抑えるためにそれを行っています。

私にとっては、masterをメインラインとしてdevelop。

また、 release- *マージモデル tomasterにいくつかの競合があり、その後にアイデアを付けてタグ付けします

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

Successfull のバージョニングでは、いくつかの bump-versionプロセス が導入されますが、自動ではありません。

つまり、リリースのブランチモデルに導入する主な違いは次のとおりです。*マージとタグ付け：-ブランチの作成時のリリースのタグ付け-将来のメンテナンスを可能にするためにリリースのブランチを保持する

1
mdn

私の場合、同じソフトウェアの2つのバージョンがあり、基本は同じですが、各バージョンにはいくつかの異なる機能があります。

したがって、2つのworktreeを作成します。つまり、マスターの横に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は混乱しません。

お役に立てば幸いです。

1
vaheeds