git上传文件时报错及解决方案

使用git的过程中，难免会遇到一些报错，以下总结一些我遇到的坑，以便自己再次遇到时可快速解决，希望对大家也有帮助：

 

--- 关于git提示 "warning: LF will be replaced by CRLF" 的警告：

格式化与多余的空白字符，特别是在跨平台情况下，有时候是一个令人发指的问题。由于编辑器的不同或者文件行尾的换行符在 Windows 下被替换了，一些细微的空格变化会不经意地混入提交，造成麻烦。虽然这是小问题，但它会极大地扰乱跨平台协作。
其实，这是因为在文本处理中，CR（CarriageReturn），LF（LineFeed），CR/LF是不同操作系统上使用的换行符，具体如下：

换行符‘\n’和回车符‘\r’

• 回车符就是回到一行的开头，用符号r表示，十进制ASCII代码是13，十六进制代码为0x0D，回车（return）；
• 换行符就是另起一行，用n符号表示，ASCII代码是10，十六制为0x0A， 换行（newline）。

所以我们平时编写文件的回车符应该确切来说叫做回车换行符。

应用情况

• Dos和Windows平台： 使用回车（CR）和换行（LF）两个字符来结束一行，回车+换行(CR+LF)，即“\r\n”；
• Mac 和 Linux平台：只使用换行（LF）一个字符来结束一行，即“\n”；
• 最早Mac每行结尾是回车CR 即'\r'，后mac os x 也投奔了 unix。

许多 Windows 上的编辑器会悄悄把行尾的换行（LF）字符转换成回车（CR）和换行（LF），或在用户按下 Enter 键时，插入回车（CR）和换行（LF）两个字符。

影响：

• 一个直接后果是，Unix/Mac系统下的文件在Windows里打开的话，所有文字会变成一行；
• 而Windows里的文件在Unix/Mac下打开的话，在每行的结尾可能会多出一个^M符号。
• Linux保存的文件在windows上用记事本看的话会出现黑点。

这些问题都可以通过一定方式进行转换统一，例如，在linux下，命令unix2dos 是把linux文件格式转换成windows文件格式，命令dos2unix 是把windows格式转换成linux文件格式。

情况一：

Git 可以在你提交时自动地把回车（CR）和换行（LF）转换成换行（LF），而在检出代码时把换行（LF）转换成回车（CR）和换行（LF）。 你可以用git config --global core.autocrlf true 来打开此项功能。 如果是在 Windows 系统上，把它设置成 true，这样在检出代码时，换行会被转换成回车和换行：

#提交时转换为LF，检出时转换为CRLF
$ git config --global core.autocrlf true

情况二：

如果你是 Windows 程序员，且正在开发仅运行在 Windows 上的项目，可以设置 false 取消此功能，把回车保留在版本库中：

#提交检出均不转换
$ git config --global core.autocrlf false

总之：

--- git 的 Windows 客户端基本都会默认设置 core.autocrlf=true，设置core.autocrlf=true, 只要保持工作区都是纯 CRLF 文件，编辑器用 CRLF 换行，就不会出现警告了；

--- Linux 最好不要设置 core.autocrlf，因为这个配置算是为 Windows 平台定制；

--- Windows 上设置 core.autocrlf=false，仓库里也没有配置 .gitattributes，很容易引入 CRLF 或者混合换行符（Mixed Line Endings，一个文件里既有 LF 又有CRLF）到版本库，这样就可能产生各种奇怪的问题。

 

 

--- 提交代码时遇到一个有关于 “字体” 的警告：

具体警告内容为：“Warning: Your console font probably doesn’t support Unicode. If you experience strange characters in the output, consider switching to a TrueType font such as Lucida Console!”

 其中“Lucida Console”是一种字体;

 解决方法：

    --- 在打开的cmd窗口的标题栏上点击右键，选择“属性”;

         

 

    --- 点击切换到“字体”选项卡;

         

 

    --- 将“新宋体”设置为当前字体，如果有其它字体也可以，只要不是选择“点阵字体”即可，然后点击确定;

         

 

    --- 再执行git add命令，就会看到没有显示之前的warning警告信息了。

 

 

--- 提交代码时遇到一个有关于 “ ! [rejected]        master -> master (non-fast-forward) error: failed to push some refs to 'https:/” 的警告：

! [rejected] master -> master (non-fast-forward)

当我们向github做push的时候经常会被rejected，解决方法有pull和rebase两种，这一集里我们讨论一下这两种方式的异同。

推荐视频：http://happycasts.net/episodes/10?autoplay=true

 

当要push代码到git时，出现提示：

error:failed to push some refs to ...

Dealing with “non-fast-forward” errors
From time to time you may encounter this error while pushing:

$ git push origin master
To ../remote/
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to '../remote/'

$ git push origin master  
To ../remote/  
 ! [rejected]        master -> master (non-fast forward)  
error: failed to push some refs to '../remote/'  

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'non-fast forward'
section of 'git push --help' for details.
This error can be a bit overwhelming at first, do not fear. Simply put, git cannot make the change on the remote without losing commits, so it refuses the push. Usually this is caused by another user pushing to the same branch. You can remedy this by fetching and merging the remote branch, or using pull to perform both at once.
In other cases this error is a result of destructive changes made locally by using commands like git commit --amend or git rebase. While you can override the remote by adding --force to the push command, you should only do so if you are absolutely certain this is what you want to do. Force-pushes can cause issues for other users that have fetched the remote branch, and is considered bad practice. When in doubt, don’t force-push.

 

问题（Non-fast-forward）的出现原因在于：git仓库中已经有一部分代码，所以它不允许你直接把你的代码覆盖上去。于是你有2个选择方式：

1，强推，即利用强覆盖方式用你本地的代码替代git仓库内的内容

git push -f

2，先把git的东西fetch到你本地然后merge后再push

$ git fetch

$ git merge

这2句命令等价于

$ git pull

$ git pull 

可是，这时候又出现了如下的问题：

 

上面出现的 [branch "master"]是需要明确(.git/config)如下的内容
[branch "master"]
remote = origin

merge = refs/heads/master

这等于告诉git2件事:

1，当你处于master branch, 默认的remote就是origin。

2，当你在master branch上使用git pull时，没有指定remote和branch，那么git就会采用默认的remote（也就是origin）来merge在master branch上所有的改变

如果不想或者不会编辑config文件的话，可以在bush上输入如下命令行：

$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

$ git config branch.master.remote origin  
$ git config branch.master.merge refs/heads/master  

之后再重新git pull下。最后git push你的代码吧。

 

--- git无法pull仓库 refusing to merge unrelated histories

如果合并了两个不同的开始提交的仓库，在新的 git 会发现这两个仓库可能不是同一个，为了防止开发者上传错误，于是就给下面的提示, 

    

在Github新建一个仓库，然后把本地一个写了很久仓库上传。这时会发现 github 的仓库和本地的没有一个共同的 commit 所以 git 不让提交，认为是写错了 origin ，如果开发者确定是这个 origin 就可以使用 --allow-unrelated-histories  告诉 git 确定。

遇到无法提交的问题，一般先pull 也就是使用 git pull origin master 这里的 origin 就是仓库，而 master 就是需要上传的分支，因为两个仓库不同，发现 git 输出 refusing to merge unrelated histories 无法 pull 内容。

因为是两个不同的项目，要把两个不同的项目合并，git需要添加一句代码，在 git pull 之后，这句代码是在git 2.9.2版本发生的，最新的版本需要添加 --allow-unrelated-histories 告诉 git 允许不相关历史合并。

假如我们的源是origin，分支是master，那么我们需要这样写git pull origin master --allow-unrelated-histories 如果有设置了默认上传分支就可以用下面代码 : git pull --allow-unrelated-histories

PS：这个方法只解决因为两个仓库有不同的开始点，也就是两个仓库没有共同的 commit 出现的无法提交。

 

 

 

 

（后续如果遇到其他的，会进行更新。未完待续。。。）