2

[ http://nvie.com/posts/a-successful-git-branching-model からの分岐モデルに固執しようとしている間 、つまり機能ブランチを使用してそれらを開発ブランチにマージし直そうとすると、次のような状況に遭遇することがあります:

機能base(機能ブランチと Python パッケージの両方) は完全であると見なされ、 にマージされdevelopます。stuff現在、 を必要とする機能 (=branch&package)baseが分岐されており、開発中に、最初からそこにあるはずだったstuffいくつかの変更/拡張が必要であることに気付きました。baseでは、どのブランチでパッケージを変更する必要がありますbaseか?

  • ブランチでこれを行うのstuffは間違っているように思われます。なぜなら、いつ (そしてもし)マージバックされたとしても、 の変更は のbase一部になるはずだからです。devstuff
  • への（再）分岐base、変更、両方へのマージはdevelop、stuff一方で多くのマージを作成します。機能ブランチにマージするのが良い方法かどうかはわかりません。特にそれがマイナーだが重要な変更である場合
  • また、( 経由でgit cherry-pick) 2 回コミットすることも適切ではありません。
  • オーバーキルみたいbaseなgit submodule音になって
  • stuff更新されたものにリベースするdevelopと、履歴が見栄えが良くなりますが、他の人が元のブランチをプルした場合に通常の問題が発生しますstuff-私の単一開発者の場合は問題ではありませんが、この問題の単なる可能性は、私が何か根本的に間違ったことをしていることを示唆しています. ..
4

1 に答える 1

0

https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.htmlの「ルール: トピックブランチ」によると、推奨は

  • トピックの作業を続けるためにブランチ other からの新機能が必要であることがわかった場合は、other をトピックにマージします。(ただし、これを「習慣的に」行わないでください。以下を参照してください。)

「下」の読み方

ルール: 適切に定義されたポイントでのみ下流にマージします

正当な理由がある場合を除いて、ダウンストリームにマージしないでください。アップストリームの API の変更はブランチに影響します。ブランチが上流にきれいにマージされなくなりました。等

そうしないと、マージされたトピックに突然複数の (適切に分離された) 変更が含まれます。結果として生じる多くの小さなマージは、履歴を大幅に混乱させます。後でファイルの履歴を調査する人は、そのマージが開発中のトピックに影響を与えたかどうかを確認する必要があります。アップストリームは、「より安定した」ブランチに誤ってマージされることさえあります。等々。

要約すると、これは「必要であればマージbaseするが、決してマージしない(おそらく に関係のない他の機能が含まれているため)」ことを意味します。stuff developstuffstuff

于 2013-05-28T13:20:17.063 に答える