2

master現在、より長期的な機能リリース ブランチであるワークフロー3.0と、次の週かそこらでリリースが予定されているような番号付きのブランチがあります。

3.0上記の例では、 master にマージする必要がある直前の変更をいくつかプッシュしています。頻繁にマージしないと、master最新の変更がなければ時代遅れになってしまいます。途中でマージすると、 から3.0までのマージでいっぱいのログができmasterます。

魔法のように見えるコマンドgit-rerereがこの問題を解決しているように見えますが、更新が必要なローカル トピック ブランチに対してのみです。3.0つまり、公開されていない 1 人のマシン上にのみ存在する場合に機能します。

すべての醜いマージ ノイズなしでマスターを最新の状態に保つ方法はありますか? rerere の使い方は理解できましたか？

4

1 に答える 1

2

rerere「記録された解像度の再利用」の略です。過去に行った決定を思い出すことで、マージ/リベースを容易にするだけです。実際に発生したときにノイズが少なくなるわけではありません。許可されているのは、マージを行わずに長くすることです (マージを「プリフライト」して結果をプッシュしないため)。

「ログがマージでいっぱいになる」ことが問題になるのはなぜですか? git log --no-mergesマージコミットなしでログを表示するために使用できます。

あなたのオプションは基本的にこれです：

  • マージの頻度を下げると、マージが必要になったときにマージが難しくなります
  • より頻繁にマージし、ログにマージ コミットを保持する
  • リベースを使用し、パブリック リポジトリに伴う問題に対処する
  • チェリー ピッキングを使用します。つまり、ブランチは履歴を共有しません。
于 2013-01-14T18:11:34.877 に答える