从/sf/ask/17360801/
当您推送到远程存储库的已签出分支时，通常会收到警告，而Git将不允许您这样做。
但是我暗示git可以将Loeliger的2ed版本从带有Git的Version Control中推送到远程存储库的当前分支，尤其是粗体文本：
推送操作可以更新存储库状态，包括HEAD commit。也就是说，即使远端的开发人员什么也没做，分支引用和HEAD可能会更改，与检出的文件和索引不同步。
积极在发生异步推送的存储库中工作的开发人员将看不到该推送。但是该开发人员的后续提交将发生在意外的HEAD上，从而产生了奇怪的历史记录。强制推送将丢失其他开发人员的推送提交。该存储库中的开发人员还可能发现自己无法与上游存储库或下游克隆协调其历史记录，因为它们不再像应有的那样简单快速。她也不知道为什么：存储库已经从她下面悄悄地更改了。猫和狗将生活在一起。不好
因此，鼓励您仅将其推送到裸仓库中。这不是一成不变的规则，但这对普通开发人员来说是一个很好的指南，被认为是最佳实践。在一些实例和用例中，您可能希望将其推送到开发存储库中，但是您应该完全理解其含义。当您确实要推送到开发存储库时，您可能需要遵循两种基本方法之一。
在第一种情况下，您确实确实希望在接收存储库中有一个工作目录，其中包含一个已检出的分支。例如，您可能知道，没有其他开发人员在那里进行过积极的开发，因此，没有人会因为无声更改被推入其存储库而盲目地站在一边。
在这种情况下，您可能希望在接收存储库中启用一个钩子，以对某个分支（也可能是刚刚推送的分支）执行检入操作。为了在自动检出之前验证接收存储库处于健全状态，挂钩应确保非裸存储库的工作目录不包含任何编辑或修改的文件，并且在推入时其索引中没有处于暂存但未提交状态的文件发生。如果不满足这些条件，则可能会因结帐覆盖而丢失这些编辑或更改的风险。
在另一种情况下，推送到裸机存储库也可以很好地工作。根据协议，每个推送更改的开发人员都必须推送到未签出的分支，该分支仅被视为接收分支。开发人员从不推送到期望被检出的分支。特别是由某些开发人员来管理签出哪个分支以及何时签出。也许那个人负责处理接收分支并将它们合并到主分支，然后再签出。
是否暗示git可以推送到远程存储库的当前分支？（我的猜测是，但是我不确定）
最后一段之前的段落（该段落建议使用钩子来检出通过push更新的分支）是否假定要推送到的分支不是远程存储库中的当前分支？（我的想法是，签出要推送到的分支暗含了要推送到的分支不是当前分支，但是最后一段指出了推送到非签出分支的“不同情况”，这对我意味着上一段是关于推送到已签出分支（即当前分支）的信息
从Git 2.3+开始，您可以将接收端配置为“具有在接收存储库中签出了分支的工作目录”。
具体来说：“推送到结帐”（git 2.4，2015年5月），该功能在“推送到结帐”（git 2.3，2015年2月）的基础上进行了改进。
有关具体示例，请参见“ 使用Git push部署项目 ”。
首先：推送部署（git 2.3）：
您可以将更改直接推送到服务器上的存储库。如果未在服务器上进行本地修改，则将自动检出对服务器当前分支的任何更改。即时部署！
要使用此功能，您必须先通过运行以下命令在服务器上的Git存储库中启用它
$ git config receive.denyCurrentBranch updateInstead
然后推送签出钩子（git 2.4）
现在有一个
push-to-checkout钩子，可以将其安装在服务器上，以精确地自定义当用户按下已签出的分支时发生的情况。
例如，默认情况下，如果服务器上的工作树发生任何更改，则这种推送将失败。相反，push-to-checkout挂钩可以尝试将任何服务器端编辑与新的分支内容合并，或者可以使用推送的分支内容的原始副本无条件覆盖任何本地更改。
简而言之，您可以直接推送到已签出的分支。注意事项，
请参见commit 4d7a5ce：
仅更改工作树而不更改索引仍然是要保护的更改；
需要保护工作树中未被一键部署覆盖的未跟踪文件；
碰巧使文件与要推送的文件相同的更改仍然是要保护的更改（即，功能的清洁要求比检出要求更严格）。
京公网安备 11010802040832号 | 京ICP备19059560号-6 