7

最近、私は複数の機能ブランチを開発中であるというこの繰り返しのシナリオを持っているようです。1つの機能ブランチ（下の写真）は、別の不完全な機能（で開発された）feature-bのサポートに依存しています。feature-a

---o---o--o                    master
       |
       +---o---o---o           feature-a
                   |
                   +----o---o  feature-b

変更するたびにfeature-a（機能のエラーを修正するためのインタラクティブなリベースを含む）、にリベースfeature-bする必要がありますfeature-a。これらはローカルブランチなので、自由に変更できます。

多くの場合、次のようなケースがあります。

             master                                         testing
---o---o--o-------------------------------------------o---o
       |              feature-a                      .   .
       +---o---o---o                                .   .
                   |           feature-b           .   .
                   +----o---o .....................   .
                   |           feature-c             .
                   +----o---o .......................

ここで、テストブランチは、開発中のすべての（関連する）機能の組み合わせであり、関連するすべての機能ブランチをマージすることによって生成されます（図master、、、および含意によってfeature-b）。feature-cfeature-a

現在、特により複雑な機能のブランチ関係がある場合はgitk、ブランチ関係を視覚化し、このリベースを自動的に行うためのシェルスクリプトを維持するために常に開いていますが、この方法は壊れやすく、一般的に厄介なようです。私が知りたいこと：

  1. ブランチの関係を記述し、さらに自動的に検出する方法はありますか？次に、1つのコマンドで、記述された関係を強化してみてください（上記の簡単な例では、feature-aリベースまたはヘッドに新しいコミットを追加して変更した後、自動的にリベースfeature-bを実行しますの新しい頭feature-a）。
  2. 一連のブランチを他のコミットにリベースするためのGUIツール（競合によって操作が妨げられる場合は単にエラーを出すだけで問題ありません）？
  3. このブランチの混乱を管理する他のアイデアはありますか？偶発的な複雑さは、時間がかかりすぎ、脳力を消耗しすぎています。
4

1 に答える 1

3

私は他の人に見られるように悪いものをプッシュするのは好きではありません、そして私は最終的な歴史をきれいに見せ続けるのが好きです。

これは悪い習慣です。「提案された更新」masterのためにとを保持する必要があります。puコミットをにプッシュし、必要に応じてpuリベースpuしmasterます。時が来れば、チェリーピックを選択しpuたり、にマージpuしたりすることもできますmaster。

これは、gitリポジトリ自体で行われる方法です。無限の分岐の「うさぎの穴から」落ちるのは避けてください。

関連している

于 2012-12-27T03:57:42.317 に答える