問題タブ [cherry-pick]

リポジトリフォルダーに一連のコミットがあるとします...

リビジョン 117 以降のすべての変更を含み、リビジョン 118 および 120 の変更を含まない作業コピーを取得したいと考えています。

編集: おそらく問題をより明確にするために、118 と 120 で行われた変更を元に戻し、他のすべての変更を保持したいと考えています。このフォルダーには、数百のサブフォルダーに数千のファイルが含まれています。

これを達成するための最良の方法は何ですか？

ブルーノとバートのおかげで、答えはコマンドです（この場合、完全なマージが実行された後に 120 を削除するため）

リビジョン番号は先頭にマイナスを付けて指定する必要があることに注意してください。「120」ではなく「-120」

私がリポジトリのメンテナーであり、寄稿者から変更を取り込みたいと仮定すると、いくつかの可能なワークフローがあります。

1. 私はcherry-pickそれぞれリモートから（順番に）コミットします。この場合、git はコミットをリモート ブランチとは無関係として記録します。
2. 私mergeはブランチ、すべての変更を取り込み、新しい「競合」コミットを追加します (必要な場合)。
3. 私mergeはリモート ブランチから個別に (再び順番に) コミットし、すべてを 1 つにグループ化するのではなく、コミットごとに競合を記録できるようにします。
4. 完全を期すために、rebase（オプションと同じcherry-pick？）を行うことができますが、これにより貢献者が混乱する可能性があることを理解しています。多分それはオプション1を排除します。

ケース 2 と 3 の両方で、git は 1 とは異なり、コミットのブランチ履歴を記録します。

cherry-pick説明されている方法または方法のいずれかを使用する場合の長所と短所は何mergeですか? 私の理解では、方法 2 が標準ですが、単一の「競合」マージで大規模なコミットを解決することは、最もクリーンな解決策ではないと感じています。

リモート リポジトリ (origin/master) にあるコミットがあり、そのリポジトリから作成されたブランチ (origin/remote_branch) に入れたいと考えています。

そのリモートブランチにチェックアウトするとき

次に、私が行ったコミットを厳選しました

git は、プッシュしようとすると、すべてが最新であると言います。

私が間違っていることはありますか？

Mercurial/TortoiseHg で、次の例を考えると、リビジョン "G" を D、E、および F を使用せずにリポジトリ A にマージする最も簡単な方法は何ですか (G は D、E、または F に依存していないと仮定します)。

パッチは最善の策ですか？

私は2つの枝を持っています。コミットaは一方の頭であり、もう一方はb、c、d、eおよびfの上にありaます。、、、を commit せずに最初のブランチに移動cしたい。チェリー ピックを使用するのは簡単です。最初のブランチを 1 つずつチェリー ピックでチェックアウトし、2 番目のブランチを最初のブランチにリベースします。しかし、1つのコマンドですべてをチェリー ピックする方法はありますか?defbcfcf

以下はシナリオの視覚的な説明です ( JJDに感謝):

あるブランチから別のブランチにチェリーピックしたいのですが、それらは大きく分岐しました。ファイルの特定の部分を変更したコミットのリストを取得するにはどうすればよいですか?

git ではできないことを質問しているように感じますが、質問することもできます。1 つの変更を加えてすべてのブランチにコミットする方法はありますか? たとえば、AUTHORS ファイルまたは LICENSE ファイルを変更したいとします。変更を 1 つのブランチにコミットしてから、各ブランチに個別にチェリー ピックできることはわかっています。しかし、それを行う簡単な方法はありますか？

私は私だけがgitを使用している立場にあり、他のすべての人はsvnを使用しています。私は「gitsvn」を使用してチームsvnに接続しましたが、ほとんどの場合、問題なく動作します。最近、私は最初に自分でプロジェクトを開始し、別のgitリポジトリを作成しました。次に、プロジェクトからsvnにデータをマージする必要があります。ただし、リリース間で自分のプライバシーで実装を微調整し続けたいと思います。

では、プライベートリポジトリからsvn-clonedリポジトリへのコミットをチェリーピックする最も簡単な方法は何でしょうか？要件は、完全なローカル履歴を保持し、ピックごとに1つのsvnコミットのみを持つことです。それとも、やらなければならない潰しがありますか？

これを実現する方法として、svn-clonedリポジトリの別のオリジンとしてプライベートリポジトリを取得する方法はありますか？

当社は現在、単純なトランク/リリース/修正プログラムの分岐モデルを使用しており、どの分岐モデルが会社または開発プロセスに最適かについてアドバイスを求めています.

1. ワークフロー / 分岐モデル

   以下は、私が見たこの 3 つの主な説明ですが、部分的に互いに矛盾しているか、その後に遭遇した問題を整理するのに十分ではありません (以下で説明します)。したがって、これまでのところ、私たちのチームはデフォルトでそれほど優れたソリューションではありません。あなたは何か良いことをしていますか？

   • gitworkflows(7) マニュアルページ
   • (nvie) 成功した Git ブランチ モデル
   • (reinh) アジャイルチームのための Git ワークフロー

2. マージとリベース (絡み合った履歴とシーケンシャルな履歴)

   pull --rebaseタスクが完了するまでメインラインへのマージを待つ必要がありますか? 個人的には、タスクがどのベースで開始および終了されたかを視覚的に示すことができるので、マージを好みmerge --no-ffます。ただし、他の欠点があります。また、多くの人は、マージの有用な特性、つまり交換可能ではないことに気づいていません(トピック ブランチを master にマージすることは、master をトピック ブランチにマージすることを意味するわけではありません)。

3. 自然なワークフローを探している

   私たちの手順が単純なルールで特定の状況を捉えていないために、間違いが起こることがあります。たとえば、以前のリリースに必要な修正はもちろん、必要なすべてのブランチにアップストリームをマージできるように、十分にダウンストリームに基づいている必要があります (これらの用語の使用法は十分に明確ですか?)。しかし、開発者がそれをさらに下流に配置する必要があることに気付く前に、修正がマスターに組み込まれることがあり、それが既にプッシュされている場合 (さらに悪いことに、マージまたはそれに基づく何か)、残りのオプションはチェリーピッキングです。それに伴う危険。そのような単純なルールは何を使用しますか?また、これには、他のトピック ブランチを必然的に除外する 1 つのトピック ブランチのぎこちなさが含まれます (それらが共通のベースラインから分岐していると仮定します)。開発者は、書いたばかりのコードがもうそこにないような気がして、別の機能を開始するために機能を終了したくありません。

4. (cherry-pick による) マージ競合の作成を回避するにはどうすればよいですか?

   マージ競合を作成する確実な方法のように見えるのは、ブランチ間でチェリーピックすることです。それらは二度とマージできませんか? どちらかのブランチで同じコミットを元に戻す (これを行う方法は?) を適用すると、この状況が解決する可能性がありますか? これが、私が大部分のマージ ベースのワークフローを推奨しない理由の 1 つです。

5. トピックの枝に分解する方法は?

   トピック ブランチから完成した統合を組み立てることは素晴らしいことだと認識していますが、多くの場合、開発者による作業は明確に定義されておらず (「突っついている」だけの場合もあります)、一部のコードが既に「その他」のトピックに含まれている場合は、上記の質問によると、そこから再び持ち出すことはできませんか? トピックブランチの定義/承認/卒業/リリースにどのように取り組んでいますか?

6. もちろん、コードのレビューや卒業などの適切な手順は素晴らしいものです。

   しかし、これを管理するのに十分なほど複雑にならないようにすることはできません - 何か提案はありますか? 統合ブランチ、イラスト？

以下は、関連する質問のリストです。

• デプロイされたアプリケーションをホットフィックス可能にするための優れた戦略は何ですか?
• 自社開発でのGit活用の流れ解説
• 企業向け Linux カーネル開発の Git ワークフロー
• 開発コードと製品コードをどのように維持していますか? （このPDFをありがとう！）
• git リリース管理
• Git チェリーピック vs マージ ワークフロー
• 複数のコミットをチェリーピックする方法
• 選択したファイルを git-merge でマージするにはどうすればよいですか?
• コミットの範囲をチェリーピックして別のブランチにマージする方法
• ReinH Git ワークフロー
• 元に戻すことのない変更を行うための git ワークフロー
• マージをチェリーピック
• OSとプライベートコードを組み合わせた適切なGitワークフロー?
• Git でプロジェクトを維持する
• Git が変更された親/マスターとファイルの変更をマージできないのはなぜですか。
• Git ブランチ / リベースのグッド プラクティス
• 「git pull --rebase」で問題が発生するのはいつですか?
• 大規模なチームで DVCS はどのように使用されますか?

また、Plastic SCM がタスク駆動型開発について書いていることも確認してください。Plastic を選択しない場合は、nvie の分岐モデルとサポート スクリプトを調べてください。

2つのブランチが分岐しており、一方のブランチ（すべてではない）からの特定のコミットをもう一方のブランチに導入する必要があることを考えると、gitcherrypickはまさにそれを実現します。

しばらくすると、2つのブランチを完全にマージする必要があります。gitは、それが再導入されないように、過去にチェリーピックされたコミットがすでにあることをどのように知るのでしょうか？