将更改推送到远程存储库时，此 Git 警告消息是什么？

What is this Git warning message when pushing changes to a remote repository?

提问by Coocoo4Cocoa

The description is a bit terse. I simply added a file on my local master branch and pushed it back to a remote repo. Any idea why this is coming up?

描述有点简洁。我只是在我的本地 master 分支上添加了一个文件并将其推送回远程仓库。知道为什么会出现这种情况吗？

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning: 
warning: To squelch this message, you can set it to 'warn'.
warning: 
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.   

采纳答案by J?rg W Mittag

Actually, it means pretty much exactly what it says: somebody is working in the repository that you are pushing to, and that somebody has currently checked out the exact same branch that you are pushing to.

实际上，它的意思几乎与它所说的完全相同：有人正在您推送到的存储库中工作，并且有人当前已签出与您推送到的完全相同的分支。

This is very confusing, because now he thinks that he has checked out the latest version of the branch, when, in fact, you have just updated the branch to a newer version. So, when he now runs git commit, hiscommit will essentially revert all the commits that you just pushed. And when he runs git diffhe will see the opposite of everything you just pushed, even though he maybe hasn't even changed anything.

这很令人困惑，因为现在他认为他已经检查了分支的最新版本，而实际上您刚刚将分支更新到了较新的版本。因此，当他现在运行时git commit，他的提交基本上会还原您刚刚推送的所有提交。当他奔跑时，git diff他会看到与你刚刚推动的一切相反的东西，即使他可能甚至没有改变任何东西。

For that reason, it is generally considered bad practice to push to a non-bare repository; you should only ever push to bare repositories, i.e. repositories that do not have an attached working copy. At the very least you should make sure that you do not push to the currently checked-out branch, but generally you shouldn't just shove your code into someone else's repository, you should ask them to pull from you instead.

出于这个原因，推送到非裸存储库通常被认为是不好的做法；您应该只推送到裸存储库，即没有附加工作副本的存储库。至少你应该确保你没有推送到当前签出的分支，但通常你不应该只是将你的代码推送到其他人的存储库中，你应该要求他们从你那里拉取。

In some special cases, like when you are serving a website from a Git repository and you want to update the website by pushing to it, it actually makes sense to push to the currently checked-out branch, but in that case you must make sure that you have a hook installed that actually updatesthe checked-out working copy, otherwise your website will never be updated.

在某些特殊情况下，例如当您从 Git 存储库为网站提供服务并希望通过推送更新网站时，推送到当前签出的分支实际上是有意义的，但在这种情况下，您必须确保你安装了一个钩子来实际更新签出的工作副本，否则你的网站将永远不会更新。

回答by VonC

With Git 2.3.0 (After February 2015)

使用 Git 2.3.0（2015 年 2 月之后）

If nobody is working in that remote non-bare repo, then it should be possible to push to a checked out branch.

如果没有人在该远程非裸存储库中工作，那么应该可以推送到已检出的分支。

But to be more secure in that operation, you now can (with Git 2.3.0, February 2015), do in that remote repo:

但是为了在该操作中更安全，您现在可以（使用 Git 2.3.0，2015 年 2 月）在该远程存储库中执行以下操作：

git config receive.denyCurrentBranch updateInstead

It is more secure than config receive.denyCurrentBranch=ignore: it will allow the push only if you are not overriding modification in progress.

它比 config 更安全receive.denyCurrentBranch=ignore：只有当您没有覆盖正在进行的修改时，它才会允许推送。

See commit 1404bcbby Johannes Schindelin (dscho):

见提交1404bcb由约翰内斯Schindelin（ ）dscho：

receive-pack: add another option for receive.denyCurrentBranch

When synchronizing between working directories, it can be handy to update the current branch via 'push' rather than 'pull', e.g. when pushing a fix from inside a VM, or when pushing a fix made on a user's machine (where the developer is not at liberty to install an ssh daemon let alone know the user's password).

The common workaround – pushing into a temporary branch and then merging on the other machine – is no longer necessary with this patch.

The new option is:

updateInstead

Update the working tree accordingly, but refuse to do so if there are any uncommitted changes.

receive-pack: 添加另一个选项 receive.denyCurrentBranch

在工作目录之间同步时，通过 ' push' 而不是 ' pull'更新当前分支会很方便，例如当从 VM 内部推送修复时，或者当推送在用户机器上进行的修复时（开发人员不在那里）安装 ssh 守护进程的自由，更不用说知道用户的密码了）。

这个补丁不再需要常见的解决方法——推送到一个临时分支，然后在另一台机器上合并。

新选项是：

updateInstead

相应地更新工作树，但如果有任何未提交的更改，则拒绝这样做。

---

---

The commit 4d7a5ceadds more tests, and mentions:

该承诺4d7a5ce增加了更多的测试，并提到：

The previous one tests only the case where a path to be updated by the push-to-deploy has an incompatible change in the target's working tree that has already been added to the index, but the feature itself wants to require the working tree to be a lot cleaner than what is tested.

Add a handful more tests to protect the feature from future changes that mistakenly (from the viewpoint of the inventor of the feature) loosens the cleanliness requirement, namely:

• A change only to the working tree but not to the index is still a change to be protected;
• An untracked file in the working tree that would be overwritten by a push-to-deploy needs to be protected;
• A change that happens to make a file identical to what is being pushed is still a change to be protected (i.e. the feature's cleanliness requirement is more strict than that of checkout).

Also, test that a stat-only change to the working tree is not a reason to reject a push-to-deploy.

前一个测试仅测试了以下情况：push-to-deploy 要更新的路径在已经添加到索引的目标工作树中有不兼容的更改，但功能本身想要要求工作树比测试的要干净得多。

添加一些更多的测试来保护功能免受未来的更改（从功能的发明者的角度来看）错误地放宽了清洁度要求，即：

• 仅对工作树进行更改而不对索引进行更改仍然是需要保护的更改；
• 需要保护工作树中的未跟踪文件，该文件将被推送部署覆盖；
• 碰巧使文件与正在推送的文件相同的更改仍然是需要保护的更改（即该功能的清洁度要求比签出的要求更严格）。

此外，测试对工作树的仅统计更改不是拒绝推送部署的理由。

With Git < 2.3.0 (Before February 2015)

Git < 2.3.0（2015 年 2 月之前）

The most common approach is to create a bare repository from the non-bare repository and have both the remote/local non-bare git repos point at the newly created bare repository.

最常见的方法是从非裸存储库创建裸存储库，并将远程/本地非裸 git 存储库指向新创建的裸存储库。

回答by pluskid

This is the same problem as This question, the solution is to use git init --bareor git clone --bare.

这个问题和This question一样，解决方法是用git init --bareor git clone --bare。