【问题标题】:Git error when trying to push -- pre-receive hook declined尝试推送时出现 Git 错误——预接收挂钩被拒绝
【发布时间】:2011-12-20 15:08:37
【问题描述】:

当我尝试推送我已提交的更改时,我收到以下错误...

git.exe push -v --progress  "origin" iteration1:iteration1

remote: *********************************************************************
To ssh://git@mycogit/cit_pplus.git
! [remote rejected] iteration1 -> iteration1 (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@mycogit/cit_pplus.git'

发生了什么事?

【问题讨论】:

  • pre-receive hookon mycogit 中有什么?
  • 你不会试图将大文件推送到 github 吧?
  • 仅供参考:今天我所有的同事都收到了这个错误消息,最终我们决定重新启动我们的存储服务器,它神奇地得到了修复。我们不知道问题到底是什么。
  • 首先,您应该检查您的分支权限或白名单。

标签: git


【解决方案1】:

您应该在git@mycogit/cit_pplus.git 询问维护回购的人。

您的提交被该 repo 的 pre-receive hook 拒绝(这是一个用户可配置的脚本,旨在分析传入的提交并确定它们是否足以被 repo 接受)。

让那个人更新钩子也是一个好主意,这样它就会打印拒绝的原因。

如果维护者是您自己,那么您在服务器端的设置似乎有问题。那么请分享更多信息。

【讨论】:

  • 在我的例子中,BitBucket 对提交消息内容进行了验证,并与当时处于离线状态的 JIRA 票证对质。
  • 所以当它上线后就固定了?
  • 在我的情况下,生成提交的用户名和 BitBucket 中的用户名不匹配。我无权更新 BitBucket 用户名,因此我不得不重置我的提交并使用更新的用户名再次提交。您可以使用此命令更新 git 用户名git config user.name 'UpdatedUserName'
  • 在我们的例子中,bitbucket 不允许任何人推送到这个分支。
  • 在我的情况下,我必须在 bitbucket 上找到 repo 设置并在 Hooks 设置下禁用验证提交者。
【解决方案2】:

我敢打赌,您正在尝试非快进推送,而钩子会阻止它。如果是这种情况,只需在推送之前运行 git pull --rebase 即可将您的本地更改基于最新的代码库。

【讨论】:

  • 这太棒了。现在我可以再次推拉,但​​在此之前我需要将上游设置为git branch --set-upstream-to=origin/myBranch。为您的回答 +1。
  • 在一个新的存储库中,我推送了一个分支(不是主分支),然后重新设置它的基础并在推送过程中出现错误。我没有找到网络挂钩。我执行了git pull --rebase,不得不再次变基并且能够推送分支。最后我发现我的分支被保护了。
【解决方案3】:

这可能是因为您没有将提交推送到 master 等分支的访问权限。您可以要求维护者授予您推送提交的权利。

【讨论】:

  • 我认为这是正确的,但有趣的是 VS 似乎试图推送到父分支而不是实际的分支名称到远程。因此,如果父分支受到保护,这似乎正在发生,但在 VS 中似乎没有更正此问题,您必须切换到 cmd 行。
【解决方案4】:

我在尝试合并文件大小大于远程存储库允许的大小的更改时遇到了这个问题(在我的例子中是 GitHub)

【讨论】:

【解决方案5】:

文件大小很重要。单个文件的限制为 ~120MB。就我而言,使用 Visual Studio 的 .gitignore 列出了该文件,但该文件仍被提交。在使用 git cli 时,我们可以得到更详细的错误信息。

pre-receive hook 被拒绝是由于大文件。基本上验证了推送。

为了解决它,我使用以下命令删除了最后一次提交:

git reset --soft HEAD~1

然后我从提交中排除了该文件。

注意: 使用 HEAD~N 返回 N 次之前的提交。 (即 3、4) 始终使用 --soft 开关来维护文件夹中的更改

希望对你有帮助。

【讨论】:

  • 这很有帮助,因为我的问题是一个不需要的 SQL 转储文件(文件大小为 155mb)被推送(意外)。
  • 文件大小限制取决于您的托管服务提供商。 GitHub 在这个大小上有一个限制,对于其他人来说它会有所不同,而自托管的 git 自然没有这样的限制。
  • 如果你在被拒绝推送后已经有多个提交怎么办?这是我的情况,在尝试推送到 repo 之前,我在之前的一次提交中有一个不需要的大文件(627MB)
  • 我无意中上传了一个 CSV 文件。所以在我的情况下,错误是由于这个。
  • 如果您有多个提交,请增加索引以将头部重置回该提交。例如,使用 HEAD~3 可以返回到之前的三个提交。始终使用 --soft 开关来维护文件夹中的更改。
【解决方案6】:

我在 GitLab 服务器进行一些更改时收到此消息。第二天推送效果很好。无论如何,正如其他人指出的那样,请与您的维护人员确认。

【讨论】:

  • 刚遇到这个问题,我猜 GitLab 正在做出改变。给它10分钟,它工作。我没有改变任何东西。
  • 刚刚也遇到了这个问题。对于可能想要检查是否是这种情况的任何人:status.gitlab.com
【解决方案7】:

就我而言,我收到此消息是因为分支在 GitLab 中被标记为“受保护”。

【讨论】:

【解决方案8】:

我在尝试推送到 dokku 实例时遇到了这个问题。原来我的服务器上的磁盘已满。

跑: du -f

结果是:

Filesystem      Size  Used Avail Use% Mounted on
udev            476M     0  476M   0% /dev
tmpfs           100M  4.4M   95M   5% /run
/dev/xvda1      7.8G  7.4G  8.9M 100% /

【讨论】:

    【解决方案9】:

    在我的例子中,我们有提交消息的钩子,我们的服务器脚本接受提交,如果它们具有提交消息"<JIRA ID><Message>" 的特殊格式。如果相应的 Jira 票证不存在或提交消息中有一些特殊符号,则它(挂钩)拒绝提交。当我在提交消息中添加 /、[、> 等时,我遇到了这个错误,删除这些工作正常。

    【讨论】:

    • 这个答案不太可能有帮助,因为原始发布者(以及将来访问的任何其他人)将有一个不同的脚本配置为预接收挂钩。
    【解决方案10】:

    这实际上是在 BitBucket 在服务器端启用 YACC 时发生的。 YACC 允许在提交消息中提及 JIRA 问题名称。因此,每当您提交任何内容时,至少将您的 JIRA 编号保留在提交消息中,然后您还可以添加自己的消息。

    【讨论】:

      【解决方案11】:

      我遇到了同样的问题。
      为我解决的问题是切换到另一个分支,然后回到原来的分支。

      不确定下划线的原因是什么,但这解决了它。

      【讨论】:

      • 我也无法推送到新分支
      • 这里也一样。 git checkout -b test 然后 git checkout master 是我必须做的所有事情才能获得推送权限。然后git branch -d test 当然是为了保持清洁:-)
      【解决方案12】:

      对我来说远程 git 服务器上的授权解决了这个问题。

      【讨论】:

        【解决方案13】:

        我正在使用 GitKraken,我们创建了一个本地分支,然后我们在其中合并了两个远程分支,然后我们尝试将本地分支推送到原点。它没有与相同的错误消息一起工作。

        解决方案创建本地分支并首先将其推送到原点,然后进行合并。

        【讨论】:

          【解决方案14】:

          在我的情况下,这是因为我不小心将一个巨大的文件添加到了我未提交的推送中,无论我之后执行什么 pull、reset 或 rm 操作,我都无法摆脱它。

          我的肮脏解决方案但可行的解决方案是重命名当前目录,将目录重新克隆到本地并将更改手动反映到重新克隆的本地目录...

          听起来不太好,但是很管用……

          【讨论】:

          • 我遇到了同样的问题,并使用 $ git reset --soft HEAD~1 作为@ozkary 建议的帮助。
          【解决方案15】:

          问题:“PUSH Failed refs/head/ - pre-receive hook denied”

          我遇到了无法将我的更改推送到我的原始分支以及任何特定项目存储库的主分支的问题,因为该存储库的大小超过了 2GB 的硬限制。它正在抛出错误。 那是因为我们在不知不觉中将测试数据从其他测试分支推送到了bitbucket。

          PUSH 失败的 refs/head/ - pre-receive hook 被拒绝

          因此尝试检查是否与其他项目 repo 相同,并且它们没有任何问题。

          修复:

          我的同事注意到,当我们将项目克隆回本地时,项目的大小为 110MB。因此,我们开始清理我们之前合并的分支和不再需要的活动分支。 一旦对几个分支进行了清理,我们意识到 repo 的大小从 2GB 急剧下降到 120MB。然后我们尝试将更改推送到我的分支,并且成功了。

          【讨论】:

            【解决方案16】:

            如果它对某人有帮助:

            我有一个空白仓库,没有要取消保护的主分支(在 Gitlab 中),所以在运行 git push -u origin --all

            • 我必须先运行git push -u origin master
            • 暂时解除对 master 分支的保护
            • 其余的推送 (--all & --tags)

            【讨论】:

              【解决方案17】:

              我的错误是该项目没有创建任何分支,我的角色是开发人员,所以我无法创建任何分支,请求他们给我相关的权限和一切现在!

              【讨论】:

                【解决方案18】:

                Bitbucket:检查设置中的分支权限(可能在“全部拒绝”上)。 如果这不起作用,只需clone your branch to a new local branch,将更改推送到远程(将创建一个新的远程分支),然后创建一个 PR。

                【讨论】:

                  【解决方案19】:

                  在检查我有开发人员访问权限并且无法发布新分支时,我遇到了同样的错误。添加更高的访问权限解决了这个问题。(Gitlab)

                  【讨论】:

                    【解决方案20】:

                    我在 GitHub gist 中遇到了这个错误。 我试图用子目录中的文件推送提交。 原来gist只能在根目录下有文件。

                    【讨论】:

                    • 也有这个。原来 repo 有文件 "snippets\\csharp.json" 这让 git 在 Windows 上遇到了困难。
                    【解决方案21】:

                    您的遥控器尚不存在默认分支(例如master)。因此,您首先需要在 git 远程服务器中创建 master 分支(例如,创建默认的 README.md 文件)然后尝试使用此命令 push 所有现有的本地分支:

                    git push -u origin --all
                    

                    【讨论】:

                      【解决方案22】:

                      在我的情况下,我有一个新的存储库,推送了一个分支('UCA-46',而不是'master'),重新设置它,再次强制推送并得到错误。不存在网络挂钩。我按照@ThiefMaster 的建议执行了git pull --rebase,不得不再次变基并且能够推送分支。但这是一种奇怪而困难的方式。

                      然后我看到Git push error pre-receive hook declined。我发现我的分支变成了protected。我删除了保护,可以再次强制推送。

                      【讨论】:

                        【解决方案23】:

                        删除受保护的分支选项或允许开发人员或管理员等其他角色允许遇到此错误的这些用户进行合并和推送。

                        【讨论】:

                          【解决方案24】:

                          在今天(2020 年 4 月 21 日)Bitbucket 自动更改政策之前,对我来说一切正常。这恰好与今天最近推出的名为Workspaces 的新功能保持一致,所以我怀疑它与此有关。

                          解决方法:我(作为管理员)按照说明在 UI 中将电子邮件地址添加到用户(您正在使用的电子邮件可以找到 git config --list

                          【讨论】:

                            【解决方案25】:

                            有时候,因为你推送的分支已经被保护了,所以你可以要求仓库的维护者改变保护状态。在 git-lab 中,您可以在

                            中找到它
                            Settings > Repository > Protected Branches .
                            

                            :)

                            【讨论】:

                            • 感谢 Gitlab,它的工作方式也一样!
                            【解决方案26】:

                            我在尝试删除远程分支时收到此消息(git push origin --delete [branch-name])。问题是分支在 bitbucket 中被标记为不可删除。

                            【讨论】:

                              【解决方案27】:

                              我有权限问题,在获得正确的权限后,我能够推送内容。我正在将现有项目推送到新的 git 存储库中。

                              【讨论】:

                                【解决方案28】:

                                您应该查看日志。我刚刚遇到了同样的错误并从日志中意识到这是因为我有一个 yarn.lock 和 package-lock.json

                                【讨论】:

                                  【解决方案29】:

                                  就我而言,我收到此错误是因为已经存在同名的分支。从 git 服务器中删除此分支将解决此问题。

                                  【讨论】:

                                    【解决方案30】:

                                    如果您在执行 Push 时遇到与 git 中的 pre-receive hook 相关的问题。 您可能有以下原因:

                                    1. 您的项目路径 app_data 中的数据库备份可能超出了 Github 限制为 100.00 MB。
                                    2. 如果您在项目中使用的文件未超过 10.00MB 或任何文件的大小限制,请检查文件的大小。

                                    您可以通过以下步骤解决此问题:

                                    1. 只需压缩这些文件并再次推送 git push -u origin develop

                                    【讨论】:

                                      猜你喜欢
                                      • 2015-04-03
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 2020-03-12
                                      • 2012-01-03
                                      • 2022-01-01
                                      • 1970-01-01
                                      相关资源
                                      最近更新 更多