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

描述有点简洁.我只是在我的本地主分支上添加了一个文件并将其推回到远程仓库.知道为什么会这样吗？

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'.   

VonC.. 84

与Git 2.3.0,2015年2月

如果没有人在那个远程非裸仓库中工作,那么应该可以推送到已检出的分支.

但是为了在这个操作中更加安全,你现在可以(使用Git 2.3.0,2015年2月)在远程仓库中做:

git config receive.denyCurrentBranch updateInstead

它比配置更安全receive.denyCurrentBranch=ignore:只有当你没有覆盖正在进行的修改时才会允许推送.

见提交1404bcb由约翰内斯Schindelin( )dscho:

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

在工作目录之间进行同步时,通过" push而不是" 更新当前分支可能很方便pull,例如从VM内部推送修复程序时,或者在用户计算机上进行修复时(开发人员不在此处)安装ssh守护进程的自由,更不用说知道用户的密码了.

这个补丁不再需要常见的解决方法 - 推入临时分支然后在另一台机器上合并.

新选项是:

updateInstead

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

---

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

前一个仅测试了push-to-deploy要更新的路径在目标的工作树中已经添加到索引中的不兼容更改的情况,但该功能本身想要求工作树是比测试的更干净.

添加少量更多测试以保护该功能免受未来的更改(错误地从该功能的发明者的角度来看)放松清洁度要求,即:

仅对工作树进行更改而不对索引进行更改仍然是要保护的更改;

工作树中未被跟踪的文件将被推送到部署覆盖,需要加以保护;

使文件与正在推送的文件相同的更改仍然是要保护的更改(即,功能的清洁度要求比结帐更严格).

另外,测试对工作树的仅限统计更改不是拒绝推送部署的理由.

与Git <2.3.0,2015年2月

最常见的方法是从非裸存储库创建一个裸存储库,并在新创建的裸存储库中同时具有远程/本地非裸git存储库点.

1> VonC..：

---

与Git 2.3.0,2015年2月

如果没有人在那个远程非裸仓库中工作,那么应该可以推送到已检出的分支.

但是为了在这个操作中更加安全,你现在可以(使用Git 2.3.0,2015年2月)在远程仓库中做:

git config receive.denyCurrentBranch updateInstead

它比配置更安全receive.denyCurrentBranch=ignore:只有当你没有覆盖正在进行的修改时才会允许推送.

见提交1404bcb由约翰内斯Schindelin( )dscho:

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

在工作目录之间进行同步时,通过" push而不是" 更新当前分支可能很方便pull,例如从VM内部推送修复程序时,或者在用户计算机上进行修复时(开发人员不在此处)安装ssh守护进程的自由,更不用说知道用户的密码了.

这个补丁不再需要常见的解决方法 - 推入临时分支然后在另一台机器上合并.

新选项是:

updateInstead

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

---

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

前一个仅测试了push-to-deploy要更新的路径在目标的工作树中已经添加到索引中的不兼容更改的情况,但该功能本身想要求工作树是比测试的更干净.

添加少量更多测试以保护该功能免受未来的更改(错误地从该功能的发明者的角度来看)放松清洁度要求,即:

仅对工作树进行更改而不对索引进行更改仍然是要保护的更改;

工作树中未被跟踪的文件将被推送到部署覆盖,需要加以保护;

使文件与正在推送的文件相同的更改仍然是要保护的更改(即,功能的清洁度要求比结帐更严格).

另外,测试对工作树的仅限统计更改不是拒绝推送部署的理由.

与Git <2.3.0,2015年2月

最常见的方法是从非裸存储库创建一个裸存储库,并在新创建的裸存储库中同时具有远程/本地非裸git存储库点.

---

在尝试保持最新状态时,在配对或频繁切换不同机器时非常有用.我还使用它来保持我的开发服务器最新(它在代码更改时自动重启),同时仍然能够在需要时进行开发.这实际上是接受的答案缺乏imo的解决方案.

2> Jörg W Mitta..：

---

实际上,它的含义几乎就是它所说的:有人正在你正在推动的存储库中工作,并且有人当前检查了你正在推送的完全相同的分支.

这非常令人困惑,因为现在他认为他已经检查了最新版本的分支,事实上,你刚刚将分支更新为更新的版本.所以,当他现在运行时git commit,他的提交将基本上恢复你刚刚推送的所有提交.当他跑步时,git diff他会看到你所推动的所有东西的反面,即使他甚至没有改变任何东西.

出于这个原因,推送到非裸存储库通常被认为是不好的做法; 你应该只推送到裸存储库,即没有附加工作副本的存储库.至少你应该确保你没有推送到当前签出的分支,但通常你不应该只是将你的代码推送到别人的存储库,你应该让他们从你那里取而代之.

在某些特殊情况下,例如当您从Git存储库服务网站并且想要通过推送更新网站时,实际上有必要推送到当前已检出的分支,但在这种情况下您必须确保您安装了一个实际更新已签出工作副本的挂钩,否则您的网站将永远不会更新.

---

Jorg,谢谢你的回应.共享存储库不应该有工作目录,但我没有用--bare初始化它.它的用途是仅用于共享工作.有一个"工作"区域,但没有人使用它.我应该裸照重新启动吗？

3> pluskid..：

---

这个问题与此问题相同,解决方案是使用git init --bare或git clone --bare.

---

`git clone --bare`为我做了伎俩.谢谢.

---

它说，即使在裸回购。（我所做的只是将git软件从1.5版升级到1.7版）

---

从1.5升级到1.7似乎会触发此消息。我做了“ MV reponame reponame.old; git clone --bare reponame.old reponame”来解决这个问题。我还必须使用“ --shared = group”并修复组权限，因为我正在运行共享存储库。