問題タブ [git-cherry-pick]

TFS で開始され、その後 Git に移行されたプロジェクトがあります。残念ながら、それを Git に移動した人は、git-tfs を使用する代わりに現在のファイルをチェックインしただけです。git-tfs を使用して TFS からプルしたコミットの上に、Git で彼の新しいコミットをリベースしようとしています。

これを行うには、git-tfs コミットの上に彼のコミットをリベースするだけです。(リモートの Git ブランチが台無しになることは承知していますが、私たちは小さなチームなので問題ありません。代わりにチェリー ピッキングも試しましたが、同じ問題に遭遇しました。)

私が直面している問題は、次のような一連の競合です。

これは、これらのファイルを追加した TFS 側からのコミットと、それらを追加した Git 側のコミットとの間の競合のようです (Git リポジトリが空で始まったため)。

おそらく、このコミットをスキップするのが論理的ですが、その中には新しいファイルがいくつかあります (数百のうちの 10 など)。もちろん、それらは競合を引き起こしません。

2 つのファイルが同一であることを Git が判断できないのはなぜですか? リベースするときに使用しても--ignore-whitespace、Git には、このような同一のファイルが多数表示されます。これを解決する方法に途方に暮れています。

それは素朴な git の質問かもしれませんが、ここにあります:

プル リクエストを行う前に、私は通常、アップストリームの最新のコミットから新しいブランチを作成し、開発ブランチから重要なコミットをチェリー ピックします。次に、新しいブランチからリモート リポジトリにプル リクエストを送信します。

しかし、マージの競合は嫌いです (ただし、競合が発生した場合は git mergetool が大いに役立ちます)。これらの競合のいくつかは、cherrypicks の順序が原因であると思われます。私は通常、最も古いコミットから最も新しいコミットまで一連のコミットを選択します。これは正しいアプローチですか？または、コミットの順序は git にとって重要ではありませんか?

チェリーピッキング中にマージの競合を最小限に抑えるための他のトリックはありますか?

通常の Git マージの競合では、スリーウェイ マージで使用されるファイルの 3 つのバージョンは、おおよそ次のとおりです。

• LOCAL: 私のブランチのバージョン
• REMOTE: 他のブランチのバージョン
• BASE: 2 つのブランチの共通の祖先からのバージョン (特に、私のブランチの HEAD と他のブランチの HEAD の共通の祖先)

Git のチェリー ピックがマージの競合を生成する場合、正確に言えば、共通の祖先は存在しないため、これらはどのように決定されるのでしょうか? リベースについても同じことが言えます。

リモートのオープンソースプロジェクト（Githubなど）からローカルリポジトリのクローンを作成したとします。ローカルリポジトリにブランチを追加するなどの変更を加えます。

次の目標を念頭に置いてください。行った変更の一部は独自の目的であり、メインリポジトリには反映されません。バグ修正や機能の追加など、他の変更はコミュニティにとって重要です。メインリポジトリに貢献したい。

したがって、それに基づいて、2つの主要なブランチを想定しましょう。すべての変更に対するdev-projと、メインリポジトリに提供されるサブセットを持つdev-commです。

一般的なケースでは、特定の変更セットがdev-commに入るかどうかがわかるので、それらをブランチに分離できます。

ただし、変更をアップストリームに提供する必要があるかどうかによってブランチを決定したくない場合があります。

たとえば、Webアプリケーションのローカリゼーション（翻訳やビューの変更など）の場合を考えてみましょう。そのためのブランチを作成し、それを非公開にするつもりですが、作業中に元のコードにi18nの問題があることがわかったので、このブランチでの作業の一部としてそれらを修正します。そして、これらはWRTをi18nに変更します。これを分離して、メインリポジトリにプッシュバックします。

私の質問は次のとおりです：この状況を処理するための最良の方法を選択することです-コミットを細かくしようとすると気が散ることが心配です、そして私が誤ってプライベートとコミュニティの塊を含むコミットをした場合はどうなりますか変更した場合は、その修正を適用する必要があります。または、手動の要素が含まれている場合でも、より良い手法がありますか。

編集：大まかなスケッチで明確にします。pはローカルプロジェクト用で、cはコミュニティのために特に上流にプッシュされることを意図した変更用です。

topicAに取り組んでいる間、私たちはどの部分がコミュニティのためのものであるかについて心配したくありません。しかし、最後に、devCommにマージしてアップストリームにプッシュできるtopicAcommのようなものが必要です。

私の質問は、チェリーピッキングがこれを処理する方法であるかどうかです。これは、ドキュメント/チュートリアルをチェックすることからもっともらしい方法のようです。または、後でコードに注釈を付けるなど、他のトリックや、私が気付いていない他のトリックはありますか。

誤ってコミットが混ざり合うことは、発生する可能性のある問題の1つにすぎません。

プロジェクト リポジトリ (GitHub 上) と私のフォーク (同じく GitHub 上) があるとします。私のフォークは、プロジェクト リポジトリに (まだ) 受け入れられていない単一のファイル (バグ修正) に対する 1 つのリビジョンが含まれていることを除いて、同じです。バグ修正を含め、ソフトウェアの最新バージョンをダウンロードする方法について、サード パーティにインストール手順を提供しようとしています。

私の知る限り、彼らはこれをしなければなりません：

(myrepo を最新の状態に維持するつもりはないと仮定します。私の指示は、プロジェクトへの関与よりも長く存続させたいと考えています。プロジェクトは間もなく終了する可能性があります。また、このファイルに他の変更が加えられる可能性があると想定しているため、単純にファイル全体は安全ではありません。)

これにはいくつかの準最適性があります:

1. 2 つの Git リポジトリ全体を転送する必要があります
2. 1 つのファイルを取得するためだけに 3 つの追加コマンドが必要です。

より良い解決策はありますか？より簡単な方法で単一のリビジョンを入手できますか?

I'm trying to merge specific commits from a branch into master, and push them to origin.

Here is what I'm doing:

Where am I going wrong?

ここで懸念しているのは、別のローカル ブランチ [abc.cpp、def.cpp を含む] に古いコミットがあることです。

数か月後、これらの変更を使用したいのですが、現在のブランチでは abc.cpp がアップグレードされています。それで、私がチェリーピックすると、古いabc.cppの変更を新しいabc.cpp [最近の作業ディレクトリのコピー]に統合するようなものですか?

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

組み込みの 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 回導入しないことです。変更セットを両方のブランチに導入したマージ操作が原因です。

同僚のコミットをマージするときにいくつかの間違いを犯しました。今、それを発見したので、古いコミットを再度適用して、ファイルの変更を手動で選択する必要があります。状況は次のようになります。

Bが歴史に一度もなかったように、BをIとマージするようにもう一度尋ねるためにgitが必要です。つまり、B で異なるすべてのファイルのマージを選択するように git に依頼し、コミットする必要があります。そのようなことをするための最良のアプローチは何ですか？チェリーピックでこれを達成できますか? どのように？

昨日、メインブランチに2つのコミットを選択しましたが、そのうちの1つがマージの競合を引き起こし、それらを解決し、コミットして元の場所にプッシュしました。今日、次のエラーが発生したときにサーバーからプルしようとしています。

Gitステータスは次のとおりです。

私は無駄に次のことを試みました：

これをどのように解決できるかについてのアイデアはありますか？前もって感謝します！