2

私のチームは、「topic1」と呼ぶgitの共有トピックブランチに取り組んでいます。私はtopic1で作られたブランチでいくつかのコードのリファクタリングに取り組んでいました。これを「リファクタリング」と呼びます。定期的にtopic1をリファクタリングにマージして変更を最新の状態に保つことができますが、リファクタリングがまだ進行中であるため、リファクタリングをtopic1にマージし直していません。

最近マスターから作成された「topic2」と呼ぶ別のトピックブランチがあります。私がやりたいのは、「リファクタリング」で行った変更のみを、「topic2_refactor」と呼ぶtopic2で作成された新しいブランチにマージすることです。（つまり、リファクタリングによってのみアクセス可能で、topic1によってはアクセスできないコミットの変更。）

私はこれらの変化だけを見る方法を知っています：

git log origin/refactor --not origin/topic1

だから私がやりたいのはこのようなものです-しかしこの構文は正しくありません：

git checkout topic2
git checkout -b topic2_refactor

そしてこれ：

git merge origin/refactor --not origin/topic1

またはこれ：

 git cherry-pick origin/refactor --not origin/topic1

（上記は、後でリファクタリングブランチにマージされたマスターで発生したいくつかの変更のために、必要のないマージの競合を引き起こしているようです。）

これを実行し、後で「リファクタリング」ブランチの履歴で解決された不要なマージの競合を回避するためのクリーンな方法があることを期待していました。これは、git rebase、git filter-branchなどを使用して可能でしょうか？

4

1 に答える 1

2

--ontoオプションgit rebaseで試すことができます。これにより、リベース操作で、「トピック 1」に基づいて「リファクタリング」ブランチから適用する必要がある差分を取得し、それらを「トピック 2」に適用できます。

git co refactor
git co -b topic2_refactor
git rebase --onto topic2 topic1 # bases the diffs off of topic1, but applies them to topic2

あなたの成功は異なるかもしれません。問題のある競合が発生する可能性があります。これの欠点は、同じ変更を加えた 2 つの別々のリファクタリング ブランチが作成されることですが、これはリベースであるため、注意しないと簡単に分岐する可能性のある異なる履歴があります (常に 1 つから選択する必要があります)。他のものまたは類似のものに分岐します)。

次に、(リファクタリング後に) topic1 と topic2 の両方を master に再度マージする必要がある場合に、問題が発生する可能性があります。gitは通常、それでかなり良いですが。

リファクタリングはこれらのトピック ブランチから独立しているように見えるので、リファクタリングが終了したときにこれらの変更を両方のトピックにマージできるように、マスターからリファクタリング ブランチをリベースすることを検討します。

于 2011-04-21T19:55:16.603 に答える