重复的情况是存在的，从数学的角度考虑，可能性是2的63次方分之一。
使用的是 SHA-1 哈希算法，40位的长度
放置碰撞应该会考虑到，可以想象下比较简单，如果重复等1秒后提交，因为是有提交的时间戳的
当然还有其他情况
但一般项目可以不用担心，毕消洞念竟重复也只是理论层面的
可以想象下Linux也是通过git进行源代码管理的
将项目上传到Gitee，新建仓库到上传代陆配码以及上传过程中可能的错误和解决办法gitee是个类似GitHub的代码托管平台，现从新手入门，中间可能出现的错误也会给出解决办法。
目录
一、安装Git
二、gitee创建仓库
三、上传本地代码到早或指gitee
一、安装Git
Git - Downloads
下载后运行，一直选下一步，默认安装即可。
二、gitee创建仓库
新建仓库
仓库信息填写
之后会d出以下界面
三、上传本地代码到gitee
1.打开项目文件夹，空白处右键，点Git Brush Here
2.从创建的仓库中，依次复制粘贴输入以下代团伍码
（1）
git config --global user.name "用户名"
git config --global user.email "邮箱"
（2）
git init
（3）
git remote add origin 项目地址
（4）
git add . (add和“.”中间有空格)
（5）
git commit -m "提交描述"
（6）
git push -u origin "master"
3.如果项目文件过大，可能会出现以下错误
错误1：
那么输入依次输入以下代码
错误2：
! [rejected] master ->master (fetch first) error: failed to push some refs to ' 。。。'
出现这个问题是因为github中的README.md文件不在本地代码目录中，可以通过如下命令进行代码合并
git pull --rebase origin master
冲突的产生很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。
而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。
git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。
冲突的类型
逻辑冲突
git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
内容冲突
两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。
树冲突
文件名修改造成的冲突，称为树冲突。
比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。
$ git status
added by us:b.c
both deleted: origin-name.c
added by them: a.c
如果最终确定用b.c，那么解决办法如下：
git rm a.c
git rm origin-name.c
git add b.c
git commit
执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。
树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。
内容冲突的解决办法
发现冲突
一般来讲，出现冲突时都会有“CONFLICT”字样：
$ git pull
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failedfix conflicts and then commit the result.
但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：
error: project mini/sample
注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。
这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：
git rebase remote-branch-name
冲突解决的一般过程
merge/patch的冲突解决
先编辑冲突，然后git commit提交。
注：对于git来讲，编辑冲突跟平时的修改代码没什么族物逗差异。修改完成后，都是要把修改添加到缓存，然后commit。
rebase的冲突解决
rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也蚂毁就是把修改内容加入缓存）：
git add -u
注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。
然后执行下面命兆卖令继续rebase：
git rebase --continue
有冲突继续解决，重复这这些步骤，直到rebase完成。
如果中间遇到某个补丁不需要应用，可以用下面命令忽略：
git rebase --skip
如果想回到rebase执行之前的状态，可以执行：
git rebase --abort
注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。
编辑冲突的方法
直接编辑冲突文件
冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：
a123
<<<<<<<HEAD
b789
=======
b45678910
>>>>>>>6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c
其中：冲突标记<<<<<<<（7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。
此时，还没有任何其它垃圾文件产生。
最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）