問題タブ [cherry-pick]

のマニュアルページ git cherry-pick：

ローカルでデフォルトをに戻し、無効に-xできるようにする構成設定はありますか？-r見つかりませんでしたが、見逃した可能性があります。

別のリポジトリからコミットの範囲を選択したい場合があります。私はそれを行う2つの方法を知っています。

1.1。

また

2. git rebase --onto myBranch begin end

最初のバージョンは覚えやすいと思います。しかし、私は、チェリーピッキングが歴史を少し壊すので、マージすることと比較してどのように悪であるかについてたくさん読みました。しかし、私がまだ理解していないのは、コミットの範囲をチェリーピッキングすることと、それらをリベースすることの間に違いがあるかどうかです。--onto

違いはないはずだと思う傾向があります。私は間違っていますか？

cherry-pickブランチBからブランチAに変更したいコミットの1つに、変更された4つのファイルがありますが、そのコミット内のファイルの1つだけをブランチAに配置したいのです。ブランチAでそのファイルを取得するにはどうすればよいですか。ありがとう！

最近、すべてのリポジトリで、すべてのリポジトリに git 属性ファイルを追加しました。アイデアは、すべてのファイルで Unix EoL char を強制的に使用することでした。これにより、新しいブランチにチェックアウトした初日に大きな問題が発生し、ファイル全体に変更が表示され始めました。私たちは単にそれをコミットしました。

さて、問題は、あるブランチから別のブランチにマージする場合 (頻繁に行います)、またはチェリー ピック (より多く行う場合) にマージすると、すべてのファイルで再び競合が発生することです。

git が設定によって行末や空白の変更を無視できれば理想的です。git にこのようなものが含まれているかどうか、または回避策があるかどうかは誰にもわかりませんか?

おそらく基本的な質問です。私はブランチ間でいくつかのコミットを厳選しました。ここで、ブランチAからブランチBにチェリーピックされたコミットのリストを取得したいと思います。それを行う方法はありますか？

私はコードに取り組んでおり、このブログで説明されている状況に似ていることに気づきました。基本的に、完全に異なるコンテナーを使用する 2 つのバージョンのコードがあります。これは、異なるコンテナーを使用した場合のコードの効率を比較するために行われます。私は効率的なコンテナー メンバー関数に依存しているため、コンテナーに関してコードをジェネリックにすることはできません。そのため、最適化されたコード用と最適化されていないコード用の 2 つの git ブランチを持つアプローチを選択しました。

問題は、コードの一部を最適化した後、分岐している 2 つのブランチで共通の作業を行う必要があることです。「上流」(最適化されていない) ブランチで作業を行い、多くの競合を解決することなく、最適化されたブランチへの一般的なコミットを選択することは可能ですか?

オンラインで見つかったチュートリアルに従い、単一のファイル (競合をテストするため) といくつかのブランチを含むダミー リポジトリを作成しました。

このgit リポジトリの例では、競合を解決せずに、ブランチ「second」のコミット「02 second」を master ブランチにチェリーピックすることは可能ですか? 私は紛争の解決に反対するものは何もありませんが、それを回避できるかどうかに興味があります.

この状況での正しいワークフローは何ですか? 一般的な変更、コミット、チェリーピック + 競合の解決を適用する必要がありますか?

ブランチから別のブランチへの単一のコミットをチェリーピックしたいと思います。ファイルの名前変更は非常に一般的だと思いますが、それでも人間の介入なしに変更を適用できるようにしたいと考えています。

組み込みの cherry-pick コマンドは、特に名前が変更されたファイルへの変更と組み合わされた場合に、名前の変更を検出するように縫い付けられていないため (少なくとも私のテスト ケースでは)。

少し試してみたところ、最終的に 2 つのリベース操作を含む解決策にたどり着きました。

チェリーピックを適用したいコミットを指すターゲットという名前のブランチがあるとしましょう。チェリーピックしたいコミットは、sourceという名前のブランチによって指されています。

次に、次のコマンドを実行します。

1. source と同じコミットを指すブランチ sourceTemp を作成します (ブランチ source を保持したいため)
2. git rebase --strategy="recursive" --strategy-option="rename-threshold=30" target sourceTemp（おそらく別のしきい値を使用します。テストファイルは非常に小さいため、変更は比較的大きくなります）
3. git rebase --onto target sourceTemp~ sourceTemp

これは、ブランチsourceからtargetへの最後のコミットによって導入された変更のみを適用します。

また、テストを github に置きました。

https://github.com/fraschfn/cherry-pick

私が知りたいのは、このアプローチが実現可能かどうか、または私の単純なテスト設定でのみ機能するかどうかです!

更新：代替方法

sourceとtargetのマージ ベースにパッチをリベースします。

開始状況

DをBにチェリーピックしたい.

1. 新しいブランチパッチを作成した後、D を M にリベースします

   /li>

2. ソースの置換を取得するために C と D' をマージします

   B と D' をマージして、ターゲットのパッチを適用したバージョンを取得します

   /li>

利点は、E と F を問題なくマージできるようになったことです。別の方法: 階層のできるだけ早い段階でパッチを含めて、D を作成せずに直接 D' を作成し、リベースを保存します。

以前のバージョンより上の利点は、「新しいソース」と「パッチを適用したターゲット」の 2 つのブランチをマージでき、それが機能し (もちろんソースとターゲットのマージが機能する場合)、git が認識しているため、同じ変更セットを 2 回導入しないことです。変更セットを両方のブランチに導入したマージ操作が原因です。

git shortlog人間が読める変更の要約を作成するのに便利です。ただし、マスターブランチから変更をチェリーピックするときは、どのコミットからピックしたかを記録するため、-xフラグを使用します。git cherry-pickこれにより、ショートログにいくつかの醜さが生じます。

git shortlogこれらのチェリーピック行 (実際のログの新しい行にあります) が不要であることを簡単に伝える方法はありますか?

もちろん、たとえば を使用してそれらを除外できることはわかっていgit shortlog Version-3.5.3..3.5 | sed 's/[(]cherry picked.*$//g'ます。しかし、git は独自の注釈を認識し、それらを処理できるようにする必要があるようです。私が逃したものはありますか？

私はこれに続いて 、特定のファイルのみの変更をチェリーピックするためにgitを使用してコミットをチェリーピックしました。

チェリーピックの後、一部のファイルで競合が発生しました。つまり、ファイルには次のようなセクションがあります。

通常、git mergeでは、最愛のp4mergeを使用して競合を解決します。これは、非常に直感的でエラーがありません。

しかし、cherry-pickを使用すると、git mergetoolを使用すると、ファイルにファイルが含まれていても、マージする必要はないと表示<<<<<<されます。そのため、競合を手動で編集して解決する必要がありました。

では、どうすれば競合が存在することをgitに知らせることができますか？

ありがとうヤン

これが私のシナリオです：

githubのオープンソースプロジェクトを修正したいとしましょう。大まかに言えば、私は次のワークフローに従います。

• githubでソースプロジェクトをフォークします
• フォークをローカルに複製する
• マスターからトピックブランチを作成する
• 私の修正を行います（ここで無関係な詳細を振る手...）
• トピックブランチをgithubにプッシュ
• 元のソースプロジェクトにプルリクエストを送信する

さて、これを数回行ったとしましょう。そのため、issue＃123とissue＃456というトピックブランチがあります。元のソースプロジェクトには、マスターブランチに加えて、リリースブランチ（1.0、1.1など）があります。

このオープンソースプロジェクトのバージョン1.1を使用する独自のプロジェクトがあります。まだ安定していないので、オープンソースプロジェクトの「マスター」に対してビルドしたくありません。必要なのは、オープンソースプロジェクトの1.1ブランチのローカルビルドで、issue＃123とissue＃456の修正も含まれています。

セットアップに時間がかかって申し訳ありません...とにかく、私が現在行っているのは、my-1.1（1.1から分岐）というローカルブランチを作成し、トピックブランチから修正を選択してビルドし、結果を使用することです。私の別の依存プロジェクト。

チェリーピッキングがここに行く正しい方法であるかどうかは100％わかりませんが、マスターからの1.1以降のすべての変更（トピックブランチに存在する）が必要ないため、マージは正しくないようです。 「my-1.1」ブランチに流れ込みます。これが最善のアプローチですか？知っておくべき落とし穴はありますか？

私が考えることができる他の唯一のアプローチは、修正ごとに重複するトピックブランチを作成することです。1つはマスターからのブランチに、もう1つは1.1からのブランチに作成します。次に、マスターベースのトピックブランチからコミットを選択する代わりに、1.1ベースのトピックブランチをmy-1.1にマージできます。しかし、それは大きな問題のようです。