20

私たちのチームでは、次のように取り組んでいます。

  • GitHub リポジトリにはブランチしかありmasterません。安定していません。毎日そこにプッシュされると思います。安定版リリースにはタグを使用します (開発には GitHub のプライベート フォークを使用します)
  • 3 週間ごとに、バグ修正と新機能 (1.2.4、1.2.5、1.2.6 など) を含む新しいマイナー バージョンをリリースします。
  • また、マイナーな旧バージョンを一定期間 (数か月) 維持する必要があるため、誰かが 1.2.4 を使用し、最新バージョンが 1.2.7 であるときにバグを見つけた場合、バグの修正を要求することができます。彼らが使用するブランチで。その後、パッチ バージョン1.2.4A をリリースします。
  • パッチはかなり例外的です。通常、マイナー リリースには 1 ～ 2 個のパッチしか適用しません。ほとんどのリリースでは、パッチは行いません。

問題は、マスターと古いブランチのバグを同時に修正するための最善の戦略は何ですか?

主な戦略として次の 2 つが考えられます。

  1. でバグを修正し、次にmastercheckoutしてから、適切なコミットを選択し (バグ修正が常に保持される 1 つのコミットであると仮定します)、結果のコミットに としてタグを付けます。v1.2.4v1.2.4A

  2. をチェックアウトv1.2.4し、バグを修正してコミットし、コミットに としてタグを付け、v1.2.4Aに組み込むにmasterは、マージを行います。

私はどちらかというと最初のバージョン（いいとこ取り）に賛成ですが、賛否両論について他の方のコメントを聞きたいです。

もちろん、途中のコミットがいくつかの大きな変更を導入し、1.2.4 とマスターの両方で機能するコミットを作成できないという事実につながると、事態は複雑になる可能性があります(たとえば、関数名が変更された場合)。またはより複雑なもの）。しかし、より一般的な状況は、問題なく修正を移植できるということです。

マスターからチェリー ピッキングを行う利点:

  • 歴史はチェリーピッキングでより「食べられる」と思います。このことを考慮：

    | <- bugfix done on master
|
|
| <- v1.2.7
...
|
|
|
|
|
|
|
|
|
|  - <- v.1.2.4A (cherry-picked from master)
| / 
| <- v1.2.4

    対これ：

    | <- bugfix merged to master
|\ 
| \
|  |
|  |   <- v1.2.7
...
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  - <- v.1.2.4A (direct bugfix)
| / 
| <- v1.2.4

    間に何十ものコミットがあると考えてください。このように複数のパッチを並行して適用することを検討してください。画面の半分が汚れます。

  • で問題を修正したとしますv1.2.4が、数日後に でのパッチを求める人がいますv1.2.3。チェリーピックは最も賢明な方法です。

私が見落としていた私たちの場合、マージの利点はありますか? チェリーピッキングよりも 2 つのコミット間の接続を維持するほうがよいことは理解できますが、リリースのドキュメントを保持しており、これらすべてもそこで追跡されています。

4

2 に答える 2

28

私が取り組んできたオープンソース プロジェクトでは、修正は最初に master に適用され、そこでテストされ、その後で古いリリースにバックポートされるというのがコンセンサスのようです。これは、Linux カーネルがどのように安定版をリリースするかを見ればわかります。たとえば、開発者はメインライン用のパッチを提出しますが、安定版にも含めるように指名します。

この状況でチェリーピッキングを行う場合は、おそらく次の-xフラグを使用する必要があります。

コミットを記録するときは、元のコミット メッセージに "(cherry picked from commit ...)" という行を追加して、この変更がどのコミットからチェリー ピックされたかを示します。これは、競合のないチェリー ピックに対してのみ行われます。... [もし] 公開されている 2 つのブランチの間で良い選択をしている場合 (たとえば、開発ブランチから古いリリースのメンテナンス ブランチに修正をバックポートする場合)、この情報を追加すると便利です。

于 2012-11-07T18:24:00.547 に答える
12

あなたの戦略 2 は、最初に以前のリリース ブランチのバグを修正し、v1.2.4次にその変更を開発トランクにマージすることで、gitworkflows(7)によって提案されています。

ルール: トピック分岐

すべてのトピック (機能、バグ修正など) のサイド ブランチを作成します。最終的にマージしたい最も古い統合ブランチでフォークします。【強調追記】

その後、多くのことが非常に自然に実行できます。

機能/バグ修正を統合ブランチに入れるには、単純にマージします。その間にトピックがさらに発展した場合は、再度マージします。(必ずしも最初に最も古い統合ブランチにマージする必要はないことに注意してください。たとえば、最初にバグ修正を次にマージし、テスト時間を与え、安定していることがわかったら maint にマージすることができます。)

これがうまくいく理由の 1 つは、私の経験では、何かが削除されるよりも頻繁に追加されるためです。そのため、古いブランチで変更を行うことにより、開発で利用できる可能性のある新しい機能などに依存することを回避できます。トランク。

ただし、 masterで変更を行ってからマージする場所を決定するのではなく、変更を行うときに修正の対象となるブランチを検討する必要があります。

どちらの戦略も実行可能であり、それぞれに利点があります。

于 2014-10-08T18:52:42.750 に答える