問題タブ [cherry-pick]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
3684 参照

git - 兄弟ディレクトリからcherry-pickをgitする方法は?

git cherry-pick を使用して、名前の変更を検出せずに、あるファイルから別のファイルにコミットを適用したいと考えています (同様のファイルの多くは、誤った検出につながります)。

(マスター) directory1/file

(マスター) ディレクトリ 2/ファイル

しかし、対応するディレクトリをcherry-pickに伝える方法がわかりません。

git-1.7.5.rc1マージ戦略別名をサポートするようになり、正常に機能する別のケースがありました-Xsubtree=.

(マスター) directory1/file

(分岐) ファイル

私は呼びました

そして、(branch~95) ファイルから (master) directory1/file への変更を、名前変更の検出なしで取得して、正常に機能しました。

git cherry-pick最初のケースでは、-で呼び出してみましXsubtree=../directory1たが、うまくいきませんでした。何らかの方法で git cherry-pick に directory2 を離れてから、directory1 に移動してパッチを適用するように指示する必要があると思います。

この問題の解決策はありますか?

0 投票する
14 に答える
331504 参照

git - 特定のファイルへの変更のみをgit-cherry-pickする方法は?

複数のファイルへの変更を含む特定のコミットで変更された一部のファイルのみに加えられた変更を Git ブランチにマージしたい場合、どうすればこれを達成できますか?

と呼ばれる Git コミットstuffにファイルA, B,Cへの変更が含まれているとしますが、 のファイルおよびへの変更Dのみをマージしたいとします。仕事のように聞こえますが、ファイルのサブセットではなく、コミット全体をマージする方法しか知りません。stuffABgit cherry-pickcherry-pick

0 投票する
2 に答える
3200 参照

tfs - TFS の分岐とマージの戦略

タスクが毎日送信される TFS にチーム プロジェクトがあります。各タスクを独立して作業し、テスト後にメイン ラインにマージしたいと考えています。

現在、MAIN ブランチと、MAIN の子である DEV ブランチがあります。変更は DEV ブランチで処理され、準備ができたら MAIN にマージされます。これは、「cherry-pick」マージによって行われます。チェリーピックのマージは悪いことであり、可能な限り回避する必要があることをどこでも読んでいます。

TFS での分岐とマージについて頭を悩ませているので、チェリー ピック マージを行わずに TFS でこの目標を達成する方法について何か提案があるかどうか疑問に思っていました。

どんな助けでも大歓迎です。

重要な情報を省略した場合は、コメントを残してください。投稿を編集します。

0 投票する
1 に答える
301 参照

git - トピックブランチに基づくブランチからgitの別のトピックブランチへの変更のマージ

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

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

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

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

そしてこれ:

またはこれ:

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

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

0 投票する
1 に答える
185 参照

git - 複数のコミットをあるブランチから別のブランチに移動しますか?

私はブランチマスターと開発から始めました。私は開発に基づいてブランチ foo を作成しました。7コミット後、マスターから離れればよかったと気づきました。私は各コミットをチェリーピックできますが、大したことではありませんが、よりスマートな方法はありますか?

0 投票する
1 に答える
621 参照

tfs - メインへの一括マージ後のチェリーピッキング変更セット

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

また、Dev のいくつかの変更セット: 変更セット 1、2、および 3 と、3 つの変更セットすべてが一部のファイルに影響します。ある時点で、それらすべてを Main にマージし、3 つすべてのチェンジセットからの変更を含むチェンジセット 4 を取得します。

この時点でチェンジセット 2 もリリース ブランチにマージする必要がある場合はどうすればよいですか? Main から Release にマージしようとすると、変更セット 4 をマージしてから、File で行われた必要な編集のみを手動で含める必要があります。しかし、この場合、チェックイン後、チェンジセット 1 と 3 からの変更が含まれていないにもかかわらず、TFS はチェンジセット 4 全体をマージ済みとしてマークし、後でマージすることはありません。

各変更セットを Dev から Main に個別にマージすることで、この状況を回避できたことはわかっていますが、それは非常に面倒で、正しい方法とは思えません。

根拠のないマージを使用して、Dev から Release に直接移行することもできますが、それは極端な手段であると考えています。

他の方法はありますか?

0 投票する
4 に答える
176 参照

git - git リポジトリの一部の git 履歴を抽出して git サブモジュールを作成する -- チェリーピック?

同様の質問How to cherry-pick multiple commitsは、コミットが連続していることを前提としています。

tarball としてダウンロードしたモジュールがあります。メイン プロジェクトの git リポジトリに含めて、変更を加えました。これらの変更は、メイン プロジェクトの他のコミットに散在しています。

私は自分のやり方の誤りに気づき、モジュールを git サブモジュールに置き換えたいと考えています。現在の状態を追加することもできますが、git の履歴を保持したいと考えています。

個々のコミットを新しいリポジトリに移動するにはどうすればよいですか?


チェリーピックでこれができると思いますが、時間がかかります。ここに私が持っているものがあります:

メイン プロジェクトをリモートとして新しいレポをセットアップします (チェリー ピックができるようにします)。

メインプロジェクトで関連するコミットを見ることができますgit log ~/.vim/snippets

チェリーピックするスクリプトを作成できます

しかし、スクリプトを実行すると、マージの競合が発生します。マージとコミットを解決したら、成功した部分をチェリー ピック スクリプトから削除して、もう一度実行する必要があります。git rebase のように、これを自動的に行いたいと思います。

0 投票する
2 に答える
201 参照

macos - チェリーピッキングを使用した OS X 用の Mercurial GUI クライアント?

これは、GitX に欠けている機能の 1 つです。そのようなクライアントはありますか?

チェリーピッキングとは、コミットに特定の行のみを含める機能です。crecord に似ていますが、優れた GUI を備えています。

0 投票する
3 に答える
223 参照

git - git のブランチにまたがる同等の変更のブックキーピング クリーンアップ

多数のトピック ブランチをクリーンアップしようとしています。これは主にmaster、同じ変更が存在するために非アクティブなトピック ブランチに github のブランチ概要に誤った「n 先」インジケータが表示されないようにするためです。

これらの誤った指標がなければ、この概要ページは、古いトピック ブランチからのコミットが誤って見落とされ、マージされていないかどうかを一目で確認する優れた方法を提供しますmaster

下の図は、後でasに適用されYたブランチのコミットです(したがって、sha1 ハッシュは異なりますが、パッチ ID は同じです)。topicmasterY'

git cherry master topic適切に報告します:

git merge topicしかし、 fromを発行してこれをクリーンアップしようとすると、パッチが適用されたコンテキストが変更されたためmaster、マージの競合が発生します。Emaster

master「ねえ、あなたは本当にYすでに持っているので、そうでないことを報告するのをやめることができます.」と伝える方法はありますか? (これを自動/プログラムで適用できるようにすることが重要です。)

0 投票する
7 に答える
289 参照

cherry-pick - チェックアウトされたファイルがどのコミットから来たのかを知る方法

でファイルをチェックアウトし、git checkout $commit $filename忘れ$commitたがまだ覚えている$filename場合、どうすれば何$commitであったかを知ることができますか?