問題タブ [git-merge-conflict]

行の順序が意味を持たないファイル (メッセージ カタログなど) がいくつかあり、常に新しい行を追加するのが慣行となっています。これにより、git の競合が発生します。git には適切な順序に関する情報がありません。もちろん、それを競合としてマークすることは一般的に正しいことですが、これらのファイルについて言うように、行の順序は無意味です。

gitに「ただ追加する」ように指示する設定はありますか? または、これらの競合を減らす他の規律はありますか?

release-x.x.xマスターにマージしたいブランチがあります。ただし、プル リクエストを実行すると、何百ものマージ コンフリクトが発生します。これは、私が実行した Swift 3 の移行によるものだと思います。release-x.x.xいずれにせよ、にマージするときにファイルのすべてのバージョンを使用したいと考えていますmaster。私はやったcheckout release-x.x.xとgit merge -s recursive -X ours master。release-x.x.xで競合を解決してからプル リクエストを作成し、masterすべてのコミット履歴を保持できるように、逆に実行しています。

を実行するgit statusと、次のような出力が表示されます。

added by usの付いたものはすべて保持し、 のboth addedマークが付いたものも保持したいdeleted by themので、これらのファイルをステージングしました。と をどのように処理しdeleted by usますboth deletedか? 試してみるgit rm Pods/FirebaseInstanceID/CHANGELOG.mdと、次のエラーが表示されますPods/FirebaseInstanceID/CHANGELOG.md: needs merge。私はここで正しい軌道に乗っていますか？

私は非常に大規模なリベースの最中であり、競合を解決しながら使用していますgit rebase --continue.

複数のファイルの競合を解決しようとして途中で、私はそれを少し混乱させたことに気づきました。競合の解決を開始する前に、リベースのこの段階に戻る簡単な方法はありますか?

git rebase --abort明らかに、他の競合の修正に費やしたすべての時間を無駄にしたくありません。

次のスタック オーバーフローの質問を見つけましたが、より明確な手順を実行できます。

git rebase 中に単一の競合解決をロールバックする方法

特に、-m旗は何をしますか？path/to/wrongリベースしているブランチの名前ですか、リベースしているブランチですか、それとも特定のコミットへの参照ですか?

dev、 、uat、 の3 つの「メイン」ブランチで作業しmasterます。master次に、新しい作業には「フィーチャー」ブランチを使用devしuatますmaster。

への PR 中、uat特に 1 人の開発者は、生成された CSS でほぼ一定のマージ競合を確認します(私たちは SASS と gulp を使用しています)。

これは予想外に聞こえるかもしれませんが、差分は非常に驚くべきものです。

また：

単純な削除、数行の削除、または単に>競合が発生する理由がわかりません。

当初は行末などを見ようと思っていたのですが、これが生成されてしまい…</p>

どのように原因を調査しますか？なぜこれが起こるのか誰にも分かりますか？

すると、次の出力が得られます。

では、最後の競合ブランチとは何ですか? それをチェックする方法、その内容を確認する方法、および削除する方法がわかりません（これが最終的にやりたいことです）。

PSこれは少し前に発生しましたが、今は覚えていません。放置していたのですが、気になったので直したいと思います。

更新:Torek の回答が役に立ちました。ファイルが見つかりませんでした.git/packed-refs。ディレクトリ.git/refs/headsを見つけて、そこにある不要なファイル/ブランチを削除しました。それはそれを修正したようです。

re: 原因は、私が使用しているエディターは Atom (github から) であり、エディターから git コマンドを実行するためのパッケージをインストールしました。そのパッケージがおそらくその競合ブランチを作成したと思います。

ユーザーが「誤って」gitマージの競合を修正し、物事を壊すという問題がよく発生します。

競合があった最近のマージを見つけるために使用できるパラメーターがありませんかgit log、どの git ユーザーがその競合を解決しましたか?

場合によっては、これは誰かが master を「test」ブランチにマージするときであり、多くの人々の作業が含まれている可能性があります。

ワークフロー:-

• マスターに基づいて機能ブランチでいくつかの作業を行います。
• テストのために機能ブランチを「テスト」ブランチにマージします。
• マスターは、最新の状態に保つためにテスト ブランチにマージされることがあります。

git ワークフローは大幅に改善し、より厳密にする必要がありますが、マージの競合を誤って修正しているユーザーを見つけるために短期的にできることはありますか?

ローカル マシンに master からのブランチがあります。mergeレポをマスターする方法を知っています。しかし、質問はこれです。

他の開発者がマスター リポジトリに変更をプッシュして変更したと考えてください。同時に、ブランチからマスター リポジトリに変更をマージしようとしています。

この状況でどうなるか。

このような状況ではどうすればよいでしょうか。私は自分のブランチから次のことをしようとしました。

• ->で私の変更を追加しましたgit add *
• 次に -> でコミットgit commit -m "my commit"
• 次に、-> で私のブランチにプッシュしますgit push -u origin my_branch_name
• 次に、リポジトリを master に変更しました ->git checkout master
• 次に、ブランチを master にマージ ->git merge my_branch_name

この段階までは成功しました。次に、次のコマンドでプッシュしようとしました（数分前に、別の開発者がマスターにプッシュしました）

• git push origin master

それから次のように言います。

この段階で、私は何をすべきか。

1. マージされたステップの後に取得してpullからプッシュする必要があります (この段階でプルを取得すると、どうなりますか?) または
2. git stashのようなことをしなければならないのでしょうかpush。

これであなたの助けを願っています。どうもありがとうございました。

ファイルの履歴に「興味深い」競合解決を伴うマージ コミットが含まれている場合、 はgit logそれをスキップします。これはなぜですか? また、そのコミットを含めるにはどうすればよいですか?

HEAD（「興味深い」とは、単にバージョンを取得したり、そのままにしたりしない解決策を意味しMERGE_HEADます。）

たとえば、このサンプル リポジトリでは、問題を説明する簡単な履歴を用意しました。

マージ コミットは、まったく新しいバージョンのE行を導入することで競合を解決しました。

ただし、これについてはgit log完全に説明します。リストされているコミットは、次のE行の現在の状態を説明できませんtest.txt。

git logマージコミットを含めることができるオプションはありますか?

のような他のコマンドは、git blameその行がマージ コミットEで最後に触れられたことを示します。9fc...

(注: 上記の出力は git version によって生成され2.11.0ます。)