0

リベースが機能しないように見えるほど異なる 2 つのブランチがあります。または、リベースの方法がわかりません。

一連のファイルが削除された「パブリック」ブランチがあります（フィルターブランチを使用）。ほとんどのコミットはデルタに関して一致しますが、コミット ID はすべて異なります。dev ブランチから public ブランチに変更をプルするために、かなりの数の方法を試しました...自分のやりたいことができるとは信じがたいですが、方法がわからないだけだと思いますやれ。いずれにせよ、これはうまく機能しますが、間違っているようです。

git checkout dev
git format-patch --stdout last_sync_tag > catchup.mbox
git checkout public
git am catchup.mbox
git --skip # talks about a missing file
git --skip # talks about a missing file
git --skip # talks about a missing file

パブリック ブランチで不要なファイルをフィルターで分岐しないことを含むヒントや提案を歓迎します (ただし、それらを削除するにはどうすればよいでしょうか?)。

私のツリーは多かれ少なかれ次のように見えます:

dev: a-b-c-d-e-f-g-h-i-j-k
pub: t-u-v-w-x

t ≅ a、u ≅ c、v ≅ d、w ≅ e、x ≅ g。i、j、k は、移行したい新しいパッチです。

checkout pub
rebase --onto pub i  # I really expected this to work
4

4 に答える 4

1

「filter-branch」を使用したため、git がリベースを実行する正しいコミットを見つけるのを手助けする必要があります。

ここで推測しますが、おそらく、パブリック ブランチの先頭と、このコミットが対応する dev ブランチの場所 (フィルタリングされていない) の 2 つのバージョンを持つ「ほぼ」一般的なコミットがあると思われます。public head commit<PH>とこれが対応する dev commit を呼び出します (フィルタリング前) <DevPH>。

dev ブランチをチェックアウトしたら、次のようにします。

git rebase --onto <PH> <DevPH>

<DevPH>これは、現在のブランチ以降の各コミットによって導入されたパッチを取得し、これらのコミットを に適用するように rebase に指示します<PH>。これが必要だと思います。

編集：

質問に対するあなたの更新は、 h が dev ブランチのパブリック ストリームのヘッドに相当し、ここから dev ブランチのすべてを public ブランチに移植したいことを示しています。その場合、コマンドは

git rebase --onto pub h
于 2009-04-21T21:11:20.653 に答える
1

Git のcherry-pickコマンドが役立つ場合があります。あなたの状況では使用していませんが、うまくいくはずです。唯一の問題は、さまざまなコミットで動作するように設計されていないことです。そのため、スクリプト化/自動化する場合は、git rev-list.

繰り返しますが、私はこれを試していませんが、このような bash スクリプトが良い出発点になるかもしれません

git チェックアウト パブリック
for rev in $(git rev-list --reverse last_sync_tag..dev) ; 行う
   git チェリーピック $rev && git タグ -f last_sync_tag $rev || 1番出口
終わり
于 2009-04-21T18:06:03.810 に答える
1

公開されていない dev ブランチのファイルを定期的に管理していますか? それともただぶらぶらしているだけですか？

それらに変更を加える傾向がなく、履歴を少し書き換えても問題ない場合は、公開ブランチに基づいて単一のコミットとして作成するように手配することができます。それをパブリックにマージしますが、「-s ours」を使用して、実際に侵入するのを防ぎます（git merge -s ours に関する以前の回答）

何かのようなもの：

git checkout -b dev public
git am create-dev-only-files.patch
git checkout public
git merge -s ours dev
git checkout dev
# write more dev patches...
git checkout public
git merge dev
# and this should merge in the patches without bringing in the
#  dev-only files

したがって、その後 dev ブランチに変更を加えて公開にマージした場合、公開されていないファイルを変更していなければ、他のすべてがそのまま適用されます。ただし、公開時に抑制したいファイルのセットが変更された場合、これは注意が必要です。たとえば、パブリックブランチでコミットを開始する前に、特定のファイルのステージングを解除する pre-commit フックを追加することで、それを防ぐことができます。

于 2009-04-21T22:56:44.097 に答える
0

ファイルが必要ない場合は、.gitignore に着陸します。おそらくそれは実際のコードではなく構成であるため、追跡はまったく必要ありません。

于 2009-04-21T18:34:58.437 に答える