Git：マージ元で変更されていないファイルにマージ競合がありますか？

Question

TL; DR：純粋に理論的な観点からすると、そのファイルは上のすべてで修正されていない場合は、マスターへの分岐の（リベースではない）ことが可能にGitがをマージ中にファイルの競合を報告するためのものですブランチ（マスターから直接作成されたもの）？

デベロッパーのブランチをマスターにマージすると、私の人生の間、私はいつも修正していないことを覚えていないか、開いたことがあるファイルに競合が生じることがよくあります。だから私は十分理解していないGitの仕組みを知りたいと思っています。これは実際には特定の状況下で可能です。そうではなく、不可能な場合は、作業ツリーのいくつかのファイル私に気付かない限り（例：Eclipseのアクションの保存、自動フォーマット、行末処理など）。

私はファイルの競合だけでなく、ツリーの競合や、ファイルの削除や名前の変更や移動を伴う可能性のあることについて話しています。ここで

は（常に最新の状態）のEclipseでEGitを使用して、私の非常にシンプルな典型的なワークフローの例です：

が）私は、マスターからのdevのブランチを作成します。 "プッシュアンドプルアップストリームの設定"チェックボックスをオンにし、 "引き出すとき"のリストボックスで "マージ"を選択します（他のエントリは "ベース"、 "リベースベースのマージコミット"、 "ベースベースの対話"）。他

誰も、ローカルおよびリモートの、そのブランチにすべてでをコミットされません。私のみ、1台のコンピュータからのみ。

）私はdevブランチをチェックアウトしており、いつか私は毎日自分の変更をコミットします。すべてのコミットは、「コミット」ではなく「コミットとプッシュ」を使用して行われます。なぜなら、すべてのコミットを常にリモートブランチにしたいからです。

「コミットとプッシュ」のプッシュ部分が「拒否 - 早送りではありません」という結果になることがあります。 「プル」を行ってからプッシュ解決策を繰り返すケースでは、プッシュが「早送りしない」ことを避けるためにプルを最初に行う必要があるのが普通です。しかしこれは問題ではありません。

）私のdevブランチをマスターにマージする時が来ています。私は引っ張って元に戻し、マージを選択し、 "Merge options"の下で私のローカルdevのブランチを選択する "私はデフォルトを残す"早送りオプションの下で "スカッシュ"を選択する "早送りの場合は、 （他のオプションは、「早送りの場合はマージコミットの作成」、「早送りの場合は失敗」）。

次に、「結果：競合」が発生します。これらの競合を解決するために、場合によっては、「鉱山」（マスター）の下に赤色で表示されている競合するコードも、彼らの "（私のdevブランチ）は私が書いたものです。このファイルを変更したことのないブランチをマスターにマージすると、これまでどおりにそのファイルを変更することはありませんでした。

私の質問は、純粋に理論的な観点からは、ブランチをマスターにマージする際にGitがファイルの競合を報告することが想定される状況が存在することです。そして、もしそうなら、上記の私のワークフローはそのような状況の1つになりますか？

それはthisの複製ではありません。なぜなら、これはリベースを使用するためです。

Answer 1

更新 - 最初の...私は戻って直接質問に答えるために得ることを忘れていました

---

まず、物事を実現：あなたがプッシュすることができます前に、その後、他の誰かがコミットを行っている、引っ張って持っている場合変更して押しているブランチ上であなたの説明によると、私は100％確信することはできません - 私は特定のコマンドと設定を知っている必要があります - しかし、私はあなたが他の誰もあなたの支店にコミットしていると間違っていることを意味します。

私はgitが理論的に何かを行うことができるかどうか聞いてきたので、これは言います。なぜなら、あなたの観測で起こっていると言われているからです...しかし、これらの観察は自己一貫性がなく、正確ではありません。

ブランチに変更がないとマージできますか？

あなたが説明した条件下ではありません。あなたが何らかの理由で悪意のあるコードになっている代替マージツールを使用している場合、私は許可しません。これは不可能です。しかし、私の上記のコメントを考えれば、私はそれがここで起こっているとは思わないと言いたい。

あなたは

R -- x1 ... xN -- A <--(master) 
\ 
    o1 ... oN -- B <--(branch) 

を持っていて、masterにbranchのマージを行うしようとしていると言います。ファイルfooに競合がある場合、定義により、このことは

（A）x1とAの間のどこかfooに適用された変更p1、

（B）が存在する変化p2がありますそれはどこかo1とB間fooに適用し、そして

（C）p1とp2を "オーバーラップ"

とみなされます

図の...の背後にp2が隠れる方法はたくさんあります。たとえば、誰かがbranchからbranch2を作成し、若干の変更を加えて、branchにbranch2をマージしたとします。しかし、バックbranchへのマージははまだ他の誰かが（あなたがプッシュすることができる前にプルする必要があるだろう場合の例となりコミットやマージの外観）そのシナリオにbranchへの変更をコミットする」ことう。

だから、本当に何が起こっているのか教えてどのように？

をgitの競合が報告された場合、あなたはそれが衝突マーカを見て、考えてどのようないくつかのアイデアを得ることができます。それはあなたが覚えていない変更だけの問題なら、おそらく彼らはおなじみに見えますか？しかし、それはそうではないように思えます。

（以下のコマンドは、マージはまだ未完成であると仮定し、マージがコミットされている場合、あなたはmaster^..branchのようなものを使うだろう。..前マージへmasterにコミットを参照するために持って前にポイントがその一部です。 ）

ですから、ファイルに影響を与えているコミットものを参照してください（ただし、masterではありませんでした）

git log master..branch -- path/to/conflicted/file 

のようなものを持つことは、それをクリアしない場合は、別のステップは

をしようとするだろう

git blame master..branch -- path/to/conflicted/file 

（-Lオプションを含めることができます。希望する場合は、コンフリクトマーカのbranch側で特定された行にゼロを付けることができます。 git blameのドキュメントを参照してください。）

これは、誰に、いつ、どのようにコミットするかを教えてくれるはずです。