9

Gitまたは（バージョンにもっと興味がありますが、比較は間違いなく役立ちます）のいずれかを使用して次のワークフローを実現するための好ましい方法は何ですか？Subversion Git

  • 最近製品のメジャーリリースがあり、と呼ばれる特定のポリシヒンブランチがあるとしましょうrelease-2.0.x。

    その後、開発が継続され、いくつかの機能ブランチがに統合されましたmaster/trunk（これらは後で今後の一部になりrelease-2.1.xます）。

  • 現在、ある時点で別の機能（つまり、critical-feature）が開発され、にマージされましたmaster/trunk。この機能は非常に重要であるため、にバックポートする必要があることを認識していrelease-2.0.xます。

これは、説明されているケースの小さな疑似図です。一番上のすべてがrelease-2.0.x現在master/trunkとの間のツリーの違いをもたらし、マージの問題につながることに注意してください（そうでなければ、単純にマージしcritical-featureてこの質問を書かないようにすることができます:)

    (features added since 2.0.x, which
     should not be backported)
              ^   ^    ^
              |   |    |    (code refactorings done
              |   |    |     in master/trunk)
              \   |    /     (*) (*) (*)          
-------------------------------------------------------> master/trunk
      |                                          |
      |                                          |
      |                                          |
      \ release-2.0.x                            \ critical-feature
                                                   (should be backported)

質問：

  • VCS観点から機能のバックポートを実行するための最良の方法は何でしょうか？

  • これは、競合を解決する競合を伴うmerge対応するブランチの単純なものとして実行する必要がありますか？critical-feature

  • またはcherry-pick、これはコミットのとして実行する必要があります。コミットは、実行時ににマージcritical-featureさmaster/trunkれますか？または、ブランチcherry-picks内の各コミットのセットとしても使用できますか？critical-feature

  • 紛争解決の手順について何かアドバイスをいただけますか？release-2.0.xとの現在の違いが非常に大きく、「ナイーブ」なバックポートがコードのリファクタリングや機能の欠落、またはの後に追加されたmaster/trunkために大量の競合を引き起こす場合は、どうすればよいですか？APIrelease-2.0.x

  • 標準的なマージまたはチェリーピッキングのアプローチを除いて、このルーチンに提供する特定の何かがありますGitか？競合の量が膨大な場合、リベースSubversionは役に立たないと思いますが、明らかに、私は間違っている可能性があります。

4

3 に答える 3

2

場合によります。重要な機能が比較的単純で小さい場合は、いくつかのチェリーピックを作成できます。ただし、もちろん、機能の実装でリファクタリングされたコードを使用する可能性があるため、多くのマージ競合が発生する可能性があります。しかし、私が理解しているように、それが最も簡単な解決策になります。そして、SVNの唯一のソリューションです。

ただし、このソリューションは履歴グラフのアクションを反映していないため、混乱します。

gitを使用すると、マスターとブランチの重要な機能をリベースする別のオプションがあります。これは文字通り、両方のブランチに共通する古いコードを使用して機能を再実装する必要があることを意味します。この場合、リベースされた機能をマージできます。機能をすでにマスターにマージしている場合、リベースされた機能をマスターにマージすると、おそらく競合します（マスターにはすでにそのような実装があるため）。したがって、競合を解決しますが、変更はほぼ同じである必要があるため、ほとんどの場合は簡単です。merge-baserelease-2.0.x

リベースされた機能アプローチの良いところは、バグを見つけた場合、機能ブランチで修正し、修正をリリースブランチとマスターブランチに簡単にマージできることです。

もちろん、リベースは多くの競合を引き起こす可能性がありますが、それは機能をにバックポートする簡単な方法がないことを意味しrelease-2.0.xます。たぶん、それを再実装するだけの方が簡単でしょう。

于 2012-08-26T20:23:58.537 に答える
2

バックポート機能のすべてのアイデアは私には壊れているように見えます。重要で非破壊的な変更のみをバックポートする必要があります。機能と改善のために、新しいブランチを作成し、安定化期間を開始する必要があります。

Apache Subversionプロジェクト自体で使用されているリリースプロセスを確認してください： https ：//subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

于 2012-08-28T14:54:34.510 に答える
2

私はこのプロセスをgitで簡単にするために特別にいくつかのツールを開発しました、そして先週私はそれらについての広範なブログ投稿を書きました。特に、git cherry-menuその投稿で参照されているコマンドは、バックポートへのコミットの任意のリストを受け入れることができるため、git logお気に入りのテキストエディターを使用して、バックポートされる重要な機能を構成する、適度に慎重に選択されたコミットのリストを作成して、何かを実行できます。お気に入り：

git checkout -b release-2.0.y release-2.0.x
git cherry-menu cat commits-to-backport.txt

これは、バックポートプロセスがより構造化されていることを除いて、kanのリベースの提案に似ています。また、内部でgit notesを使用することで、プロセスを説明するすべてのメタデータがの複数の実行にわたって保持されるなど、いくつかの便利な追加機能を利用できますgit cherry-menu。

もちろん、バックポートへのコミットがほんの一握りしかない場合は、直接チェリーピックするのがよいでしょう。

残念ながら、受け入れられた答えは少し自己矛盾していると思います。

バックポート機能のすべてのアイデアは私には壊れているように見えます。重要で非破壊的な変更のみをバックポートする必要があります。機能と改善のために、新しいブランチを作成し、安定化期間を開始する必要があります。

新しいブランチを作成して安定化期間を開始することはまだバックポートであるためです。唯一の違いは、バックポートされたコミットをどのブランチに入れるかです！それらを元のブランチに入れるか、上記で提案しrelease-2.0.xたブランチのように別のブランチを分岐させることができます。release-2.0.y後者を行う方が一般的に安全でクリーンです（そしてそれがIvanのポイントだと思います）が、実際には、リポジトリとブランチをどのように編成するかによって異なります。それでも、チェリーピッキングと潜在的な競合解決を実行する必要性を回避することはできません。

于 2013-09-23T11:52:10.393 に答える