5

2 つの平行した長寿命のブランチがあるとします:masterとexperimental. そして、 のトピック ブランチでいくつかの作業をexperimental行います。これは、いくつかの機能 ( feature1、feature2、feature3) に対して行います。で行われた作業を にどのように移植しfeature2ますmasterか?

私の初期リポジトリ:

  master
    |
A-B-C
 \                              
  D-E       I       L           P
     \     / \     / \         /|
      F-G-H   \   /   \       / |
          |    J-K     \     / experimental
      feature1   |      M-N-O
              feature2      |
                         feature3

私の希望のリポジトリ：

                                   master
                                     |
A-B-C-----------------------------J'-K'
 \                              
  D-E       I       L           P
     \     / \     / \         /|
      F-G-H   \   /   \       / |
          |    J-K     \     / experimental
      feature1   |      M-N-O
              feature2      |
                         feature3

私が考えられる 1 つの方法はgit checkout master; git cherry-pick J K、エラーが発生しやすく、トピック ブランチにさまざまなコミットが含まれている可能性があることです。

私はそれが のように動作することを期待しgit checkout master; git <transplant-commits-in-topic-branch-onto-current-branch> feature2ますが、私がよく知っているすべてのリベース コマンドは、共通の祖先 (この場合はA) からすべての差分を移植しIますK。 .

ちょっとした文脈: 私はオリジナルからフォークされたコードベースに取り組んでいますが、特定の機能を提供したいと考えています。そして、すべての新機能をトピック ブランチで開発し、マスターにマージします。

4

1 に答える 1

8

feature2に移行しようとしているだけmasterで、「I」と「K」が で行われた変更に依存しないfeature1場合は、次のように移植できます。

git rebase --onto master feature1 feature2

この構文は、大まかに言うと、「にリベースfeature2しmasterます。元のアップストリームは でしたfeature1。」

次に にマージfeature2するmasterと、早送りマージになります。

ただし、feature2が の変更に依存してfeature1いる場合master、全体の状況はさらに複雑になり、何をしたいかはワークフローと親プロジェクトとの関係に完全に依存します。チェリーピッキングはうまくいきます...オリジンのマスターに対して後で複雑な機能ブランチのマージを喜んで行う限り。または、すべてのブランチをリベースして、 、または... 他の約12のメソッドfeature2に対してきれいに適用することもできます。masterそれは、これらのブランチの長期計画に大きく依存します。一般的に、あなたがそれを助けることができるなら、カットfeature2（などfeature3）をオフにします. masterこれにより、今後の多くの手間が省けます。

于 2013-08-27T16:18:11.190 に答える