3

この問題に関して Google が何を求めているのかわかりません。上記は私のXの質問です。私のYの質問は

頻繁にリベースされる親ブランチにどのように対処しますか?

次のブランチがあるとします。

STACK-123 [origin/master: ahead 3]
STACK-456 [STACK-123: ahead 7]
STACK-789 [STACK-456: ahead 4]

この依存関係チェーンもあることに注意してください

origin/master <- STACK-123 <- STACK-456 <- STACK-789

基本的に、それらすべてを一連のパッチとして扱いたいと考えています。ただし、それらのいずれかがリベースされた場合、下流のブランチはまだ古いバージョンのコミットを保持しています。

それでは、このコミットのリストがあるとしましょう:

STACK-123 (a, b, c, d) atop origin/master
STACK-456 (e, f, g) and implicitly (a, b, c, d) atop origin/master

STACK-123 がリベースされると、次のようになります。

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e, f, g) atop origin/master

STACK-456古いコミットがどのように保持されているかに注目してください。

ブランチを一連のコミットにリンクするだけで、リベース後にこの問題が発生しないワークフローは何ですか?

各ブランチを手動で修復する必要はありません。

(また、すでに公開されているコミットをリベースする危険性を十分に認識しているため、繰り返しは控えてください。これらのブランチはいずれも公開/メインライン化されていません。)

4

3 に答える 3

1

ローカル ブランチを世界にプッシュする前にのみ、ローカル ブランチをリベースする必要があります。定期的にリベースされている共有リポジトリを持つことは、Git の間違った使い方です。

(また、すでに公開されているコミットをリベースすることの危険性を十分に認識しているため、繰り返すのは控えてください。)

しかし、それは正しい答えです。

リベースは履歴を書き換えます。リベースされたブランチの一連のコミットは、リベースが行われていないローカル ブランチの一連のコミットと事実上無関係です。基本的に、リベースは、関連するチェリーピックの束を実行するためのショートカットです。

マージと分岐は、コードを git と共有する方法です。リベースは、ローカル作業を世界に公開する前にクリーンアップすることを目的としています。

于 2013-07-19T22:44:07.127 に答える
0

私が考えていた 1 つの解決策...私が現在嫌いなのは...コミット メッセージにエンコードすることで、どのコミットが実際にトピック ブランチに属しているかをエンコードすることです (とにかく JIRA スタイルの開発者が行うことです)。

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e*, f*, g*) atop origin/master

コミットe f gに何らかのマーカー (grep する文字列) がコミットに含まれている場合、ユーティリティ スクリプト (の外部git) を使用してそれらを除外できます。

a [self] STACK-123 ... relics before rebase, will be filtered
b [self] STACK-123 ...
c [self] STACK-123 ...
d [self] STACK-123 ...
f [self] STACK-456 ... contains the string 'STACK-456', will be kept
g [self] STACK-456 ...
h [self] STACK-456 ...
于 2013-07-19T22:53:16.967 に答える