github - git で 2 つのウェアハウスのコードを正しくマージする方法はありますか?

Question

あるウェアハウスAからコードを直接ダウンロードし、その後自分でウェアハウスBを構築しました。その結果、作成者の最新のコードを同期したいと考えています。倉庫 A にアクセスすると、オンライン同期方法は役に立たないことがわかりました
/q/10...

私が使用した方法は、最初に致命的な報告を提出することであり、無関係な履歴の統合を拒否することでした

グーグルで検索した後、--allow-unpopular-histories パラメータを追加しました

これで実行できるようになりましたが、ソースコードをマージした結果は驚くべきものでした。この場合、Git はソースコードの違いを認識できないようです。たとえば、まったく変更していないコードファイルがあります。しかし、ソースの作成者は自分で更新しました
私のバージョンは
111
222
です作者のバージョンは
111
222
333
理論的には、マージでは 333 をソース コードに直接マージするだけです。ただし、この場合、git は私のコンテンツと作者のコンテンツが完全に一致しているとみなします。 2 つの異なるコピーがあるため、コードは次のように変更されました

リーリー

なぜこのようなことが起こっているのでしょうか? 解決策はありませんか? フォークのみのソース リポジトリを同期する方法はありますが、フォーク以外の場合は多少の変更があっても同期できません。

Answer 1

github からダウンロードしたソース コードはデフォルトでは git ウェアハウスではないため、ダウンロードしたコードを git ウェアハウスに初期化します。そのようなウェアハウスには送信履歴がありません。 2 つのウェアハウス に同じ履歴 がない場合、git pull を使用してリモート ウェアハウスにマージすることはできないため、最初に使用した方法では次のようなエラーが発生します: git pull进行合并到远程仓库的，所以刚开始你用的那种方法会出现这样的错误：

refusing to merge unrelated histories

但是你使用--allow-unrelated-histories选项强制进行合并，的确是解决了这个问题。
但是，你后续出现的那个问题是很正常的，git并没有认为你的内容和作者的内容是完全不同的两份，只是二者产生了冲突，即在相同的地方出现了差异。遇到冲突，手动解决就可以了。而且据我猜测，之所以会产生冲突，很可能是windows换行符和Unix换行符不统一的原因(当然我们肉眼是看不出来的)，这个就看你在git设置如何处理换行符了。也许远程仓库换行符统一使用的是Unix换行符(LF)或者windows换行符(CLF)，而你恰好相反。关于在git设置如何处理换行符，可以参考github的官方帮助文档，当然网上也有很多资料。
另外，就像前面大神所说的，最好使用git clone命令直接克隆仓库，这样就可以保留仓库的历史提交，使用git pull

無関係な履歴のマージを拒否します🎜

🎜しかし、 --allow-unpopular-histories オプションを使用して強制的にマージすると、この問題は解決されます。
しかし、後で遭遇した問題は、Git があなたのコンテンツと作者のコンテンツが完全に異なるとは考えず、単に 2 つが矛盾している、つまり同じ場所に違いがあるだけです。競合が発生した場合は、手動で解決してください。私の推測によると、競合の理由はおそらく Windows の改行と Unix の改行が一致していないためです (もちろん、肉眼ではわかりません)。 gitの設定。おそらく、リモート ウェアハウスの改行文字は Unix 改行文字 (LF) または Windows 改行文字 (CLF) を一律に使用しており、あなたはその逆かもしれません。 gitの設定における改行の扱いについては、githubの公式ヘルプドキュメントを参照してください。もちろん、インターネット上にも多くの情報があります。
さらに、マスターが前に述べたように、ウェアハウスの履歴の送信を保持し、< code>git pull コマンド エラーは発生しません。 🎜

Answer 2

これは競合の部分をマークしており、競合を解決するためにどの部分を保持するかを選択できます。

さらに、コードをコピーするだけでフォークしたくない場合は、git clone就好了，这样你的远程主机就还是作者那个，以后用git pull常に最新の状態に保つ必要があります

Answer 3

これは、GIT が変更後の同じ行を認識してマージできないためです。これを GIT では 冲突

と呼びます。

競合を手動で解決してからコミットする必要があります。競合を解決する方法は、「GIT 競合解決」も検索してください。

Answer 4

メンバーの答えはすでに正解です。 。
git add -u を使用して競合するファイルを追加できます。次に git commit -m commits を実行してから git pull
なぜあなたが言及した状況が発生するかについてです。
あなたのコードは

である可能性があります

222
実際にはここにキャリッジリターン、ラインフィード、その他の記号があります

作者のバージョンは
111
222
333

この場合、git はこれが競合であると認識し、自動的にマージしません。完全にはわかりません。 git はコードを自動的にマージしません。

Answer 5

@Fighting_Bird
テストした結果、その通りでした。落とし穴は、元の作成者のプロジェクトの .gitattributes ファイルが

に設定されていることです。

• text=auto
  このオプション、設定にこのオプションがある場合、git は送信する前にテキストドキュメントのすべての改行を LF に変更し、チェックアウト時に元に戻しますが、私自身のプロジェクトにはこの設定がないため、そのような変換操作はなく、ドキュメントの改行が異なり、マージが失敗します