3

複数のブランチが同時に使用されるプロジェクトで git を使用しています。

A ---- B ---- C
 \       \
  \       ---- D
   ---- E

すべての名前付きアイテムは、状況に応じて使用されます (つまり、A、B、D の両方にアクセスする必要があります...)。コードを変更するときは、可能な限り関連性の高いブランチ (ほとんどが A) で行い、すべてのブランチを新しい "A" にリベースして違いを伝えます。

プッシュ/プルで問題が発生するので悪い習慣だと言われ、プロジェクトに新しいメンテナーを追加する必要があるため、別の方法でやりたいと思っています。

条件付きコンパイルを提案され、初期の開発ではそのように進めていましたが、今では多くのブランチ (現時点で ~10) があり、コードが非常に読みにくくなったため、このブランチ ソリューションにたどり着きました。 ...

チェリーピッキングは見栄えがしますが、コミットごとに 10 個のコミットが行われ、B が A の子であるという事実の「視覚的な」表現が失われます...

他のアイデア、提案はありますか？ありがとう！

4

1 に答える 1

3

「git rebase」の代わりに「git merge」を使用してください。

グラフのブランチ A にバグが発生したとします。バグを示すのは最も上流のブランチであるため、それを修正します。それをチェックアウトし、修正をコーディングし、修正をテストして、A で動作することを確認します。次に、それを他の場所に伝播する場合は、次のようにします。

  1. B をチェックアウトし、A を B にマージします。
  2. E をチェックアウトし、A を E にマージします。
  3. C をチェックアウトし、B を C にマージします。
  4. D をチェックアウトし、B を D にマージします。

B で最初に問題が発生した場合は、B をチェックアウトし、修正をコーディングし、修正をテストしてから、手順 3 と 4 だけを実行します。

詳細については、このページで「上向きマージ」を検索してください。

これにより、多くのマージ操作が発生します。例では、10 の子孫ブランチの親ブランチである A を修正すると 10 になりますが、これは使用できる最も健全なワークフローでもあり、a) リベースされたコミットがプッシュされ続けるため、コラボレーターをイライラさせません。リモートに、そして b) ブランチを互いにマージする能力を完全に破壊することはありません。

b）ちなみに、これが「git cherry-pick」を望まない理由です。Cherry-pick は変更セットを A から 10 個の他のブランチに確かに伝播しますが、使用されているすべての個別のブランチでそのコミットの SHA1 ハッシュを変更します。たとえば、後で B を A にマージすると、冗長な履歴ができてしまいます。変更セットの動作は同じですが、SHA1 ハッシュがまったく異なります。これは場合によってはそれほど大したことではありませんが、ワークフローに体系化すると、惨めな方法で失敗することになります。冗長なマージ履歴は「git bisect」と「git rebase」も台無しにし、読み取ることはほとんど不可能です。この分岐モデルでは、可能な場合は「git cherry-pick」を避けてください。

于 2012-06-11T15:59:55.997 に答える