我有一个远程gitosis服务器和一个本地git存储库,每次我在代码中做大的更改时,我也会将更改推到该服务器。

但是今天我发现,即使我有一些本地更改并提交到本地存储库,当运行git push origin master时,它说“一切都是最新的”,但当我使用git clone在远程服务器上签出文件时,它不包含最新的更改。我只有一个名为“master”的分支机构和一个名为“origin”的远程服务器。

PS: 这是git在运行ls-remote时显示的内容,我不确定它是否有帮助

$ git ls-remote origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/remotes/origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c        refs/tags/stage3

当前回答

我有多个遥控器。除了一个人以外,所有人都正确地推了,所以我知道我没有一个独立的头或提交问题。

结果,我不小心给了两个遥控器相同的URL。复制URL的远程失败,因为我正在推到一个已经被推到的URL !

使用git remote -v显示了我的远程列表和它们的url,在那里我意识到问题。

重置失败的远程到其正确的URL修复了这个问题: Git remote set-url <remote-name> <correct-url>

其他回答

我有多个遥控器。除了一个人以外,所有人都正确地推了,所以我知道我没有一个独立的头或提交问题。

结果,我不小心给了两个遥控器相同的URL。复制URL的远程失败,因为我正在推到一个已经被推到的URL !

使用git remote -v显示了我的远程列表和它们的url,在那里我意识到问题。

重置失败的远程到其正确的URL修复了这个问题: Git remote set-url <remote-name> <correct-url>

验证您没有篡改远程URL。

I just wanted to also mention that I ran into this after enabling Git as a CVS in a local Jenkins build configuration. It appears that Jenkins checked out the most recent commit of the branch I gave it and also reset my remote to correspond to the paths I gave it to the repo. Had to checkout my feature branch again and fix my origin remote url with 'git remote set-url'. Don't go pointing a build tool to your working directory or you'll have a bad time. My remote was set to a file path to my working directory, so it naturally reported everything up-to-date when I attempted to push changes with the same source and destination.

我遇到过这样的情况,我在一个特征分支上,而我的同事也创建了他自己的特征分支。我运行git fetch -a,然后git push origin <coworkers_branch>。它一直告诉我一切都是最新的。

我通过检出到<coworkers_branch>,然后从我的特征分支中提取,然后提交并推回到<coworkers_branch>来修复它。

我真诚地希望这能帮助到一些人,因为我花了太多的时间在这上面。

另一个可能罕见的情况,但值得一提的是-当你在本地环境中配置了预提交钩子(扫描代码以查找错误,例如Python安全,flake8, black, isort, bandit等),如果其中一个失败了,你的提交也失败了。这在控制台中应该是显而易见的,但是由于来自钩子的错误可能会充斥控制台中,因此您可能没有意识到您的提交将无法工作,直到预提交钩子被配置为忽略问题或问题得到解决。

另一种需要注意的重要情况是:git的默认状态是您正在“master”分支中工作。在很多情况下,您只需要将其作为主要的工作分支(尽管有些人会变得花哨并做其他事情)。

不管怎样,这只是一个分支。所以我可能会遇到这样的情况:

我的活动分支实际上不是主分支. ...但我习惯执行命令:git push(我之前已经做过git push origin master,所以这是一个快捷方式)。

所以我习惯性地将主分支推到共享回购…对我来说,这可能是一件干净的好事……

但是我已经忘记了我一直在做的改变还没有在主分支!!

因此,每次我尝试git push,当我看到“Everything up to date”时,我都想尖叫,但当然,这不是git的错!它是我的。

因此,我将我的分支合并到master中,然后执行push,一切都恢复正常。