問題タブ [merge-conflict-resolution]

Gitでマージの競合が発生すると、競合するファイルに次のようなジャンクが挿入されます。3つの質問：

1. これらの注釈をどのように読みますか？
2. これらのマージの競合を修正するときに使用するいくつかの戦略は何ですか？
3. これらのファイルを読み取り、2つのバージョンを並べて表示して、問題の修正を容易にする方法を知っているMac用のGUIツールはありますか？

注：関連する場合は、GitHubのMacGUIクライアントを使用しています。

Dropbox を git リポジトリとして使用しています。

現在、同期の問題により、git に競合するコピーが存在します。この競合を取り除くにはどうすればよいですか? この競合のため、そのリポジトリのコンテンツを複製できません。

リポジトリのクローン作成中に発生するエラーは次のとおりです。

Git :- 致命的: 参照の形式が無効です: 'refs/heads/debugging (xyz conflictedcopy date) '

Git で次のことを実行しましたが、それが正しい方法であるかどうかはわかりません。私が持っているのは、いくつかのものを含むファイルです。次に、このファイルに余分なものを追加するブランチがあります (それを拡張します。別売りのプラグインです)。branch1 と branch2 に次の内容のファイルがあるとします。

次に、branch1 の主要な機能について作業を行い、そのブランチにコミットしました。その後、branch1 を branch2 にマージして、この新しい機能をファイルのプラグイン バージョンにも再適用しました。今、ファイルは

しかし、コードは完全には機能しないため、branch2 に切り替えて、そこでファイルを拡張するコードに変更を加える必要があります (「qwe」を「qwer」に変更します)。ただし、作業中にベースコード (「1234」) にいくつかの間違いが見つかり、それらを修正します (「1234」を「12345」に変更します)。HEADがbranch2にある私の作業ディレクトリには次のものがあります

今、私はこれをコミットする必要があります。私が目指している結果は

これを単に branch2 にコミットしてから、1234->12345 の変更を個別に branch1 に再適用し、それもコミットすると、探している結果が得られるのではないかと心配していますが、Git はこれを 2 つの別個の完全に独立したコミットとして認識し、将来、同様のプロセスを経るとき (たとえば、branch1 で 12345->123456 を実行し、次に branch1->branch2 をマージする場合)、その場所で競合が発生します。したがって、私の解決策は、インタラクティブなステージングを使用して、qwe->qwer の変更のみを branch2 にコミットすることです。次に、残りの変更をスタッシュし (そうしないと、ブランチ 1 に戻すことができません)、他のブランチに切り替え、スタッシュを適用し、1234->12345 をブランチ 1 にコミットし、最後にブランチ 1-> ブランチ 2 をマージします。

それはうまくいきましたが、私はGitに比較的慣れていないので、物事を正しく、可能な限り最善の方法で使用しているかどうかはよくわかりません. 上記が理にかなっている場合はお知らせください。そうでない場合は、より良い方法を教えてください。

何らかの理由で、ハエにマージの競合がある場合、git cherry-pick が他のコミットをプルするように見えます。これらは使用すると消えますgit mergetoolが、マージ競合ファイルを手動で編集することはできません。

なぜこれが起こるのか誰か知っていますか？

私の言いたいことを示すために、単一のファイルを持つ新しい git 1.7.4 リポジトリを見てみましょうfoo:

この時点で、 という新しいブランチを作成しましょうbar。マスターに戻り、このファイルに 3 つの変更を別々のコミットで追加しましょう。

コミット 1:

コミット 2:

コミット 3:

この最後のコミットは重要であるため、これをブランチbarに戻しgit cherry-pick <commit>、そのブランチでプルすることにしました。

残念ながら、これにより file で興味深いマージ競合が発生しますfoo。

git mergetool正しいことをしているように見え、これを生成することに注意してください：

マージ競合ファイルに、選択しようとしたコミットよりも前のコミットが含まれているのはなぜですか?

まず、生成されたファイルをまったくチェックインしたくないのですが、マネージャーは主張します。したがって、これらの制約を考慮して、作業レポの「生成された」という名前のすべてのディレクトリで常に「ファイル」を取得する水銀の「マージパターン」を作成したいと思います。hgrc のドキュメントと関連する投稿を読みましたが、次のようになると思います。

これはルートの .hg/hgrc ファイルに配置されます。マージ競合で hg update を実行すると、次のようになります。

そこで、「マージパターン」を次のように変更しました。

そして、ここに私が得るものがあります:

そのため、「マージ ツール internal:other が見つかりませんでした」という警告は表示されなくなりましたが、生成されたファイルをマージしようとしています。

これを機能させる方法についてのアイデアはありますか?

その他の注意事項：

1. 新しいバージョンとサブリポジトリに問題があったため、Mercurial バージョン 1.7.5 を使用しています。
2. 私はサブレポで作業しているので、メインレポの構造は次のようになります。

ビルド サーバー上で非対話モードでいくつかの Mercurial コマンドを実行するスクリプトがあります。.hgtagsコマンドの 1 つは 2 つのブランチをマージしますが、ビルド スクリプトの設定方法が原因で、マージ中にファイル内で常に競合が発生します。

.hgtagsMercurial に、最初に一方から、次に他方から、両方のファイルの変更を常に使用してファイルをマージさせるにはどうすればよいですか?

たとえば、マージするファイルが

と

私は結果が欲しい

カスタム マージ ツールが必要になると思います。この機能を提供するツールは何ですか?

私はまだeGitに慣れていません。私は、コピーを使用してeGitにマージ競合を解決させる方法を地球上で理解しようとしていますが、変更はありません。eGit Wiki のメモを参照しています。

http://wiki.eclipse.org/EGit/User_Guide#Possible_merge_results

ただし、競合を解決するために自分のコピーを追加すると、eGit はまだファイルに差分マークを残します "<<<<<<< HEAD", "=======", ">>>>>>> "。ドキュメントには、Merge-Tool を使用した後に追加するように記載されています。

満足するまで作業ツリーのバージョンを編集します チーム > マージされたリソースを追加して、競合を解決済みとしてマークします チーム > コミットを介してマージコミットをコミットします

ただし、コピーを使用して競合を解決した後もファイルに差分マークが残ります。これは実際には変更がないため、保存する必要はありません。私の質問は、ファイルに差分マーカーを残さずに、eGit にコピーを受け入れ、追加、およびコミットさせるにはどうすればよいですか? これらのマーカーは最終コミットでなくなりますか?

競合マーカーのあるファイルを2つの別々のファイルに分割するツールを探しています。これをすでに行っているものはありますか？

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

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

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

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

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

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

git-rerere不必要なマージ コミットを作成することなく、2 つのブランチ (マスター ブランチとトピック ブランチ) の間の競合の解決を、それらのブランチが発展するにつれて段階的に記録するという意図された目的で使用しています。ただし、git-rerere マンページを読んだ後でも、rerere が実際に競合解決をいつ記録するかについては少しわかりません。新しいマージの競合を検出して解決するための私の標準的なワークフローはgit merge master、トピック ブランチから実行し、競合を解決してから、すべてのファイルをステージングして でマージをコミットし、で保存された記録された解決のみを残してgit commit -m "Finished test merge"を使用してマージを元に戻すことです。git reset --hard HEAD^git-rerere

ただし、これは少しばかげているようです。コミットを作成してから、解決を記録するためだけにそれを元に戻しますか? のマンページを読んだ後でgit-rerereも、いつ私の解決策が記録されるかはよくわかりません。競合するファイルをステージングするだけで十分ですか、それとも、私が行ってきたように、競合を解決した後に実際にマージ コミットを作成する必要がありますか?