9

私は十分に確立されたソフトウェアツールキットを持っていますが、それはしばしば小さな調整を必要とします（主にサードパーティ製品からの互換性の問題に対処するために）。元のバージョンに基づく「新しい」バージョン（改良されたAPI）を作成したいと思います。これは時間の経過とともに既存のブランチから分岐しますが、数年間は元の「ライブ」を維持する必要があります。互換性のためにそれを必要とする既存の顧客。もちろん、「微調整」が「新しい」バージョンにも適用されることを確認する必要があります。そのような問題は（ほとんどの場合！）「新しい」バージョンにも適用されるためです。

つまり、私の理想的な（単純な）ワークフローは次のようになります。

  1. 「新しい」バージョンで作業する場合-変更はそのバージョンにのみ適用されます。
  2. 「古い」バージョンで作業している場合、結果として生じるすべての変更は、満足したら（コミット、送信など）、両方のバージョンに（可能な限り自動的に！）適用されます。

マージが競合する場合は、時々手動で介入する必要があることは承知していますが、過去の手動変更の経験からすると、まれであると思います。

現時点では、VSSを放棄することを検討しています（そうです-長く維持するために私を笑い続けてください！）、Gitがこれを簡単にすることを望んでいましたが、これまでのところ、「単純な」ものはありません「解決策、私が見たすべての提案は「リベース」を中心に構築されていますが、これは私には「間違っている」ように見えます。リベースは履歴の書き換えなど、他の多くのことを行うように見えるので、必要なのは単純で本物のことだけです。」他のブランチからの変更に基づいて「前進」します。

  • ここで何かが足りませんか？
  • これを行うためのより簡単で適切に定義された方法はありますか？
  • Gitではなく別のソース管理システムを使用したほうがよいでしょうか？

すべての考えは大歓迎です！

4

2 に答える 2

5

古いブランチからの変更を新しいバージョンにマージするだけです。

リベースについて詳しく説明します。コードベースで作業している唯一の開発者でない限り、この特定の問題にリベースを使用することはお勧めしません。リベースはプライベート ブランチでのみ使用することをお勧めします。履歴をリライトし、リベースされたコミットを祖先として持つすべてのコミットを無効にするためです。

古いバージョン ブランチの変更を新しいバージョンにリベースすると、古いバージョンから新しいバージョンに変更を加える必要があるたびに、新しいバージョン ブランチの履歴を書き換え続けることになります。これは、新しいバージョンのベースで行われた作業、たとえば、新しいバージョン専用の機能の機能ブランチで行われた作業は、元のコミットが存在しなくなるため失われることを意味します。

于 2012-04-22T09:24:21.830 に答える
0

Git フローをご覧ください。これは、この種の機能をサポートするツールを使用して分岐するためのアプローチです。基本的に、新しい「微調整」ごとに、維持しているブランチの共通の祖先に/前に根ざした新しいブランチでそれを行い、それをそれぞれにマージします。

于 2012-04-22T19:13:56.463 に答える