Git错误non-fast-forward后的冲突解决

当要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:

  1. $ git push origin master
  2. To ../remote/
  3. ! [rejected]        master -> master (non-fast forward)
  4. 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句命令等价于

  1. $ 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上输入如下命令行:

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

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

时间: 2024-10-31 10:09:16

Git错误non-fast-forward后的冲突解决的相关文章

Git push错误non-fast-forward后的冲突解决

当要push代码到git时,出现提示: error:failed to push some refs to ... Dealing with “non-fast-forward” errorsFrom time to time you may encounter this error while pushing: [plain] view plain copy print? $ git push origin master To ../remote/ ! [rejected]        ma

git 本地与远程仓库出现代码冲突解决方法

提交过程中报错: [[email protected] Selesystem]$ git push -u origin masterUsername for 'https://github.com': sdfasnamePassword for 'https://[email protected]': To https://github.com/nighttidesy/-Selesystem.git ! [rejected] master -> master (fetch first)error

【Todo】git的fast forward & git命令学习

git的fast-forward在之前的文章有介绍过,但是介绍的不细: http://www.cnblogs.com/charlesblc/p/5953066.html fast-forward方式就是当条件允许的时候,git直接把HEAD指针指向合并分支的头,完成合并.属于"快进方式",不过这种情况如果删除分支,则会丢失分支信息.因为在这个过程中没有创建commit squash 是用来把一些不必要commit进行压缩,比如说,你的feature在开发的时候写的commit很乱,那么

Git 分支管理 分支管理策略 不使用Fast forward模式进行合并

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit, 这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge -- 首先,仍然创建并切换dev分支: $ git checkout -b dev --- 修改readme.txt文件,并提交一个新的commit: ---- 现在,我们切换回master: -

Git merge 冲突解决简明教程

目录 1.????概述????1 2.????从git difftool & mergetool 工具开始 – Beyond Compare????1 2.1.????下载安装Beyond Compare????1 2.2.????创建启动Beyond Compare脚本????1 2.2.1.????创建git-difftool-bcomp-wrapper.sh????2 2.2.2.????创建git-mergetool-bcomp-wrapper.sh????2 2.3.????设置环境变

Git – Fast Forward 和 no fast foward

Git 很是强大,在体验过rebase的华丽之后,再次发现之前在TFS上遇到的问题一下都有解了.但也印证了Git深入并非易事.这篇就谈下一个容易迷糊的概念:Fast forward. Fast-Forward 当前分支合并到另一分支时,如果没有分歧解决,就会直接移动文件指针.这个过程叫做fastforward. 举例来说,开发一直在master分支进行,但忽然有一个新的想法,于是新建了一个develop的分支,并在其上进行一系列提交,完成时,回到 master分支,此时,master分支在创建d

git教程5-提交与no fast forward融合

每一个提交相当于一个版本,版本都有版本号与之对应.通常通过git commit -m "name"为每次提交命名. no fast forward 融合使得主分支与次分支每次提交都能够被记录下来,而不会让主分支覆盖次分支. 几个重要的命令: 1.根据版本号查看某个版本: git reset --hard versionID 2.查看版本之间的关系图 git log --graph --pretty==online --abbrev--commit 3.no fast forward融合

Git下的冲突解决

冲突的产生 很多命令都可能出现冲突,但从根本上来讲,都是merge 和 patch(应用补丁)时产生冲突. 而rebase就是重新设置基准,然后应用补丁的过程,所以也会冲突. git pull会自动merge,repo sync会自动rebase,所以git pull和repo sync也会产生冲突.当然git rebase就更不用说了. 冲突的类型 逻辑冲突 git自动处理(合并/应用补丁)成功,但是逻辑上是有问题的. 比如另外一个人修改了文件名,但我还使用老的文件名,这种情况下自动处理是能成

git pull——git库版本与本地库版本冲突总结

git库版本与本地库版本冲突:个人定义为就是git库版本与本地库版本不匹配,详细地说就是我们从git库clone克隆下来的版本,经过修改后提交并合并成新版本,但是后来又将git库的该版本撤销了,而本地没有撤销该版本,此时就是本地库拥有此版本而git库中没有此版本.这样在使用git pull或git pull origin master可能会出现:"Your local changes to the following files would be overwritten by merge&quo