I directly downloaded a code from a certain warehouse A, and then built a warehouse B myself. Note that it was not forked. It was convenient at the time. As a result, I now want to synchronize the author’s latest code from warehouse A, and then I found that the online synchronization method is useless
/q/10...
The method I used was to file a fatal report first: refusing to merge unrelated histories
After googled it, I added the --allow-unrelated-histories parameter
Now it can run, and the result of merging the source code is dumbfounding. Git seems to be unable to recognize the source code difference in this case. For example, there is a code file that I have not changed at all, but the source author has updated it himself
Mine The version is
111
222
The author's version is
111
222
333
Theoretically, the merge should just merge 333 directly into my source code. However, in this case, git considers my content and the author's content to be completely Two different copies, so it changed the code into this
<<<<<<<<<head
111
222
========
111
222
333
>>>>>>>>>>aasdasfsdfsdfWhy is this happening? Is there no solution? Is there a way to synchronize the source repository only for forks, but non-forks cannot synchronize even if they have minor changes?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
The source code downloaded from github is not a git warehouse by default, so you initialize the downloaded code into a git warehouse. Such a warehouse does not have any submission history. If the two warehouses do not have the same history , they cannot be merged into the remote warehouse using
git pull, so the method you used at the beginning will cause an error like this:But if you use the
--allow-unrelated-historiesoption to force the merge, it does solve this problem.However, the problem you encountered later is normal. Git does not think that your content and the author's content are completely different. It is just that the two conflict, that is, there are differences in the same places. If you encounter a conflict, just resolve it manually. And according to my guess, the reason for the conflict is probably because the Windows line breaks and Unix line breaks are not consistent (of course we can't see it with the naked eye). This depends on how you handle line breaks in your git settings. Maybe the remote warehouse's newline character uniformly uses Unix newline character (LF) or Windows newline character (CLF), and you are just the opposite. Regarding how to handle line breaks in git settings, you can refer to the official help document of github. Of course, there is also a lot of information on the Internet.
In addition, as the master said before, it is best to use the
git clonecommand to directly clone the warehouse, so that you can retain the historical submissions of the warehouse, and use the--allow-unrelated-histories选项强制进行合并，的确是解决了这个问题。但是，你后续出现的那个问题是很正常的，git并没有认为你的内容和作者的内容是完全不同的两份，只是二者产生了冲突，即在相同的地方出现了差异。遇到冲突，手动解决就可以了。而且据我猜测，之所以会产生冲突，很可能是windows换行符和Unix换行符不统一的原因(当然我们肉眼是看不出来的)，这个就看你在git设置如何处理换行符了。也许远程仓库换行符统一使用的是Unix换行符(LF)或者windows换行符(CLF)，而你恰好相反。关于在git设置如何处理换行符，可以参考github的官方帮助文档，当然网上也有很多资料。
另外，就像前面大神所说的，最好使用
git clone命令直接克隆仓库，这样就可以保留仓库的历史提交，使用git pullcommand to avoid errors.This marks the parts of your conflict, and you can choose which part to keep to resolve the conflict.
In addition, if you just copy a code and don’t want to fork it, you should just
git clone就好了，这样你的远程主机就还是作者那个，以后用git pullkeep it updatedThis is because the same line has been modified and GIT cannot recognize and merge it. This is called
in GIT冲突You need to manually resolve the conflict and then commit. How to resolve the conflict, please also search "GIT conflict resolution"
member's answer is already correct. .
You can use git add -u to add conflicting files. Then git commit -m commits and then git pull
As for why the situation you mentioned occurs.
It is possible that your code is
222
There are actually carriage returns or line feeds or other symbols here
The author’s version is
111
222
333
In this case, git will recognize that this is a conflict and will not automatically merge. Not completely sure. git doesn't automatically merge code.
@Fighting_Bird
After testing, you are right. The pitfall is that the .gitattributes file in the original author’s project is set in
text=auto
This option, if there is this option in the settings, git will change all the line breaks of the text document it considers to LF before submitting, and then switch it back when checking out, but my own The project does not have this setting, so there is no such conversion operation, causing the document line breaks to be different and the merge to fail