90

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

4

6 に答える 6

82

git-flow モデルでは、「最新リリース」バージョンは実際には にマップされmasterますが、「プレビュー リリース」は git-flowreleaseブランチにマップされます。実際のリリース時にフォークされdevelop、最終的にマージされます。masterその後、これが「最新リリース」になり、通常は git-flowhotfixブランチを使用して、そのリリースのバグのみを修正します。このように、master常に最新リリース バージョンの最も安定した状態を表します。

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

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

これらのブランチは開始されたばかりで、masternorにマージされることを意図していませんdevelop。これは通常は問題ありません。「古い」リリースへの修正や、「古い」リリースに実装するように顧客から要求された機能は、 に戻ることができないか、戻るべきではないためmasterです。それでもまだ考えている場合は、メインの開発ライン (masterおよび で表されるdevelop) に修正を移植したいと考えていhotfixますhotfix。

于 2013-05-31T21:15:28.890 に答える
10

ほとんどの場合、枝に重点を置きすぎたメンタル モデルのように見えます。同意します。コミットをマスターにマージする代わりに、リリースしたコミットにタグを付けることができます。

絵はきれいですけどね。すべてをマージして master に戻すと、バージョン タグがグラフ全体にばらまかれる代わりに、リリースが時系列で明確に示されます。

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

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

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

于 2013-05-15T11:11:21.207 に答える
2

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

GitHub を使用している場合は、GitHub flow(Scott Chacon の説明に従って) を試してください。

これは、複数の機能でのコラボレーション、コード レビューに特に役立ち、Commit Status API.

更新: The GitHub Flow™ の新しい公式 Web サイトがあります</a>

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

于 2013-05-15T11:22:02.260 に答える
2

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

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

私たちのチームはまた、成功したものよりもユニバーサルな分岐モデルを求めていました。つまり、上記の @Mot のように - 主なアイデアは、安定したリリースのために kernel.org によって行われているように、別の *.git リポジトリで release-* ブランチをサポートするための追加のリポジトリを導入しないようにすることです。しかし、kernel.org はダウンロード サイズを最小化するためにそれを行っていると思います。

私にとっては、 masterをdevelopmentのメインラインとして持つ方がクリーンなようです。

また、 release-* マージ モデルをマスターし、後でアイデアをタグ付けする際にもいくつかの競合があります。

マスターでコミットが発生するたびに、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 hook が自動バージョン管理をサポートするビルドを開始する場合:

$git describe --tags --long >.ver

間違ったバージョンがビルドされる可能性があります:

$ git merge --no-ff release-1.2

成功したバージョンのバージョン管理では、バンプ バージョン プロセスが導入されることは知っています が、自動ではありません。

つまり、要約すると、リリースのブランチモデルに導入する主な違い-* マージとタグ付けは次のとおりです。

于 2018-11-09T12:38:36.227 に答える
-3

マスター ブランチは常に製品コード ベースを表す必要があるため、製品リリースの直後に常にコードをマスターにマージします。

タグ付けは、製品リリースに含まれる正確なコードを「記憶」するために使用されるため、何か問題が発生した場合に後で戻ってコードを分析できます。

これにより、理論的には、コードをリリース ブランチでタグ付けするか、マスター ブランチにマージした後にマスター ブランチでタグ付けするかは問題になりません。個人的には、リリース ブランチのコードをタグ付けすることを好みます。これはまさにビルド/リリースに含まれるコードだからです (マージで何か問題が発生する可能性があると仮定して)。

開発ブランチの概念の問題は、それがシングル スレッドであることです。このスレッドの Brendan は、開発ブランチの概念に関連して使用できる戦略について言及しました。

于 2017-01-02T18:54:49.513 に答える