标签：提交代码 完成 部分 现象 1.0 代码 重要 com 不一致
冲突是指当你在提交或者更新代码时被合并的文件与当前文件不一致。读起来有点绕，结合下面的案例理解。
从上面对冲突的定义来看，冲突时发生在同一个文件上的。
常见冲突的生产场景如下
git的合并中产生冲突的具体情况：
<1>两个开发者（分支中）修改了同一个文件（不管什么地方）
<2>两个开发者（分支中）修改了同一个文件的名称
注意：两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。
总结：上面各种情况的本质都是，当前文件与合并文件不一致，因此不论哪种情况其解决冲突的方法是一样的。
模拟场景：
假设有另个开发人员开发同一个项目，并且编写同一个文件,工作流程如下：
1.01号程序员先上传文件conflict.txt，并继续在conflict.txt上写代码；
2.02号程序员更新项目代码，并在conflict.txt上写代码，写完后，在提交到远程服务端；
3.当01号程序员把写完后，准备提交代码了，这时的正规操作手法，先更新在提交，但是在更新的时候必然会冲突，因为这时候更新的代码conflict.txt与本地仓库代码conflict.txt不一致
提交前，我要更新，冲突了：
解决方案如下：
accept yours:代表以自己的为准；
accept theris:代表以更新下来的文件为准；
merge:代表手动合并
一般解决冲突我们都是选择merge
将需要的内容点击：">>"既可以合并内容到result中，不需要的内容点击“x”即可，合并完成后点击apply即可。
值得注意的是，最将所有的“x >>”符号都要处理完，不需要的点击“x”,需要的点击“>>”
最后，不论是什么场景下产生的冲突解决方法是一样的。
多人协作开发的时候,如果出现了你没有改过的文件跟你冲突了,一定要去找到当事者,说清楚是如何冲突的；
然后协商解决,千万不要擅自拉别的分支去试图解决冲突,或找文件覆盖，更或者以自己的文件为准.
同时记住,解决了之后,要add 和 commit 最后push.为保证万无一失,最后在冲突都解决之后,重启项目；
保证至少不会有立即奔溃的现象发生.然后才去提交,push.
提交的时候,一定要保持清醒,先搞清楚自己要提交的文件之间的关系,然后再提交,这样才不会有文件缺失的问题,造成奔溃.
如果任务比较多,又开了多个分支,分别进行开发,再次强调，一定要清楚自己在各个分支上做了什么,自己要提交的是什么.最好是能做个详细的笔记，没有把握宁愿不要去提交到生产服务器.
提交代码的时候不要走神,因为这是一个神圣的时刻！
标签：提交代码 完成 部分 现象 1.0 代码 重要 com 不一致
原文地址：https://www.cnblogs.com/newAndHui/p/10851807.html
