問題タブ [git-merge-conflict]

ブランチ「test1」を作成し、ファイルを変更し、マスターにマージしません。テストのことを一週間忘れる。その test1 ブランチ以降、マスターに多くの変更を加えました。

しかし、その後、私が行った test1 の 1 つの機能、変更した 1 つのファイルがまだ気に入っていると判断しました。

ブランチ test1 を master にマージすると、何がマージされますか? test1ファイルだけですか？すべての新しいマスター ファイルを古い test1 ブランチ ファイルで上書きしたくありません (変更した 1 つのファイルを除く)。

元のリモートの master ブランチから更新をプルした後、ローカルの dev ブランチにチェックインし、git rebase master を試みました。いくつかの競合がありました。これらのほとんどは簡単に解決できましたが、元のリモートでファイルの名前が変更されたという競合に行き詰まっています（ファイル名にハイフンを含めるように更新されましたが、これはローカルファイル名がなくなったことを意味します日にち）。

したがって、競合メッセージは次の行に沿っています: Auto-merging data/foldername/file-name.yml CONFLICT (content): Merge conflict in data/foldername/file-name.yml Failed to merge in the changes.

私は周りを検索しましたが、この種の競合を解決する方法について決定的な答えを見つけることができません. ローカル ファイルの名前をオリジン リモートのものと一致するように変更することで競合が解決するかどうか疑問に思いましたが、これが逆効果になるのではないかと心配しています。

任意のポインタをいただければ幸いです。ありがとう。

私は、適切に使用するために GitHub で複製することを目的としたプロジェクトに取り組んでいます。また、git に詳しくない人でも簡単に使用および設定できるように設計されています。

基本的に、プロジェクトには、クローンごとにカスタム ファイルを持つように設計されたディレクトリがあり ( ./app/assets/)、プロジェクトのクローンを作成した人が元のプロジェクトから変更をプルしたときに、それを作成したいと考えています。このファイルの何も上書き/マージしません。

私が読んだことから、この方法でプロジェクトがブランチ間でファイルをマージする方法は、カスタム マージ ドライバーをセットアップすることです (私が見てきたことの詳細はこちら) が、これは十分に堅牢ではないようです。私がやりたいことを正確に行います。

「my-clone」リモートであるリモートからのブランチ間でこれらのファイルを通常どおりマージできるようにしたいと考えていますが、元のプロジェクトからのブランチ (おそらく私の理解では「origin」という名前) が他の誰かにマージされた場合プロジェクトの「my-clone」コピーを作成した後./app/assets、リポジトリに追跡および記録されていても、元のブランチのディレクトリから競合するファイルまたは追加のファイルをマージで自動的に無視するようにします。

理想的には、ソリューションがデフォルトでリポジトリに存在するように、ソリューションをリポジトリで追跡できるようにしたいと考えています。それが不可能な場合は、アプリのクローンを作成した人が実行できるようにスクリプト化できるソリューションでも十分です。これを解決するのに役立つアイデアと学習の機会は大歓迎です!

プロジェクトへのリンク

これはおそらく長い質問になると思いますので、ご容赦ください。

ここで、git マージの決定に関する信じられないほどの説明に出くわしました: How does git merge work。私はこの説明に基づいて構築しようとしており、このように git merge を描写することに穴があるかどうかを確認しています。基本的に、マージされたファイルに行が表示されるかどうかの決定は、真理値表で表すことができます。

W: 元のファイル、A: Alice のブランチ、B: Bob のブランチ

この真理値表に基づいて、D を構築するための行ベースのアルゴリズムを考えるのは簡単です。 A と B から対応する行を見て、真理値表に基づいて決定を下すことにより、D を行ごとに構築します。

私の最初の質問はケース (0, 0, 1) で、上に投稿したリンクによると、そのケースは実際には競合していますが、git は通常、とにかく行を削除することでそれを処理することを示唆しているようです。この場合、実際に紛争につながる可能性はありますか?

2 番目の質問は、削除のケース (0, 1, 1) と (1, 0, 1) についてです。直観的には、これらのケースの処理方法が問題につながる可能性があると感じています。W に関数 foo() があったとしましょう。この関数は実際にはどのコードでも呼び出されませんでした。ブランチ A で、アリスが最終的に foo() を削除することを決定したとしましょう。しかし、分岐 B で、ボブは最終的に foo() の使用を決定し、foo() を呼び出す別の関数 bar() を作成しました。直感的に、真理値表に基づいて、マージされたファイルは foo() 関数を削除し、bar() を追加することになり、Bob はなぜ foo() が機能しなくなったのか不思議に思うでしょう! おそらく、私が 3 通りのマージのために導き出した真理値表モデルは、おそらく完全ではなく、何かが欠けていると思いますか?

git の競合について頭を悩ませようとしていますが、これら 2 つをマージすると競合が発生するのはなぜですか?

ブランチの file.txt master:

ブランチの file.txt feature:

マージしようとするとファイルが競合していると Git が言う問題に遭遇していますが、競合を解決しようとすると競合はありません。ローカルとリモートの両方が同じ場合に、Git がそれを競合と見なすのはなぜですか? Git にこれを自動的に解決させる方法はありますか?

OS: Windows8

Git バージョン: 1.9.5