Git push 出错以及server端没有显示push后的文件的解决方法

本文介绍了解决Git在推送代码过程中遇到的master->master(branchiscurrentlycheckedout)错误的方法。通过修改.git/config文件并添加特定配置,可以避免Git默认拒绝在被检出的分支上进行更新。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Git: push 出错的解决 master-> master (branch is currently checkedout)

在使用GitPush代码到数据仓库时,提示如下错误:

[remote rejected]master -> master (branch is currently checkedout)
remote: error: refusing to update checked out branch:refs/heads/master
remote: error: By default, updating the current branch in anon-bare repository
remote: error: is denied, because it will make the index and worktree inconsistent
remote: error: with what you pushed, and will require 'git reset--hard' to match
remote: error: the work tree to HEAD.
remote: error:

...

...

...

 

 

这是由于git默认拒绝了push操作,需要进行设置,修改.git/config添加如下代码:

   [receive]
   denyCurrentBranch = ignore

 

在初始化远程仓库时最好使用 git--bare init   而不要使用:gitinit

   如果使用了gitinit初始化,则远程仓库的目录下,也包含worktree,当本地仓库向远程仓库push时,  如果远程仓库正在push的分支上(如果当时不在push的分支,就没有问题), 那么push后的结果不会反应在worktree上,  也即在远程仓库的目录下对应的文件还是之前的内容,必须得使用git reset--hard才能看到push后的内容.

<think>嗯,用户遇到了Git LFS推送时的两个典型问题:missing protocol错误和LFS locking API不支持的问题。从用户描述看,ta应该是在企业内网环境使用自建Git服务,这类问题在企业私有部署中很常见。 用户可能已经尝试过基础配置但没成功,现在比较着急。ta的深层需求其实是希望LFS能稳定用于大文件管理,而不仅仅是解决报错。考虑到引用中出现的IP地址和.git后缀,基本可以确定是私有GitLab/类似平台。 missing protocol问题通常出现在SSH配置不完整。用户可能复制粘贴了http格式的URL但用了git协议,或者remote地址缺少前缀。需要特别注意:企业内网常混用http和ssh协议,容易混淆。 LFS locking API不支持的问题更棘手。私有Git服务若未升级到较新版本(GitLab 8.12+),原生就不支持LFS锁。有趣的是引用1已经给出了关键线索——建议禁用锁验证,这正是核心解决方案之一。 用户没提具体Git服务类型,所以需要给出通用解法。考虑到安全风险,应该优先推荐升级服务,其次才是禁用锁验证。如果用户用的是GitLab,禁用锁只是临时方案,最终还是要升级。 技术细节上要注意: 1. git config的locksverify参数名很长,容易拼错,在示例中必须完整展示 2. 重设remote地址时,必须强调http和ssh协议的区别 3. 测试步骤必不可少,用户需要明确知道是否修复成功 最后补充的预防措施很有必要。用户可能不知道LFS不适合超大二进制文件,这点必须提醒。另外.gitattributes的配置优先级容易出错,需要举例说明。</think>以下是针对 Git LFS 推送时出现 **missing protocol** 和 **Remote does not support the Git LFS locking API** 问题的完整解决方案: --- ### **问题原因分析** 1. **Missing Protocol** 远程仓库 URL 缺少协议前缀(如 `http://` 或 `https://`),导致 Git 无法识别传输协议。 2. **LFS Locking API Not Supported** 远程 Git 服务器(如旧版 GitLab/Gitea)未启用 LFS 文件锁功能,或未安装 LFS 扩展[^1]。 --- ### **解决方案** #### **步骤 1:修复 Missing Protocol 错误** ```bash # 检查当前 remote URL git remote -v # 若 URL 为 "192.168.1.91:8080/..." 格式(缺少协议),需重设 URL: git remote set-url origin http://lujuntao@192.168.1.91:8080/r/CSharp/IntelligentBuilding.git # 或使用 SSH 协议(若支持): git remote set-url origin git@192.168.1.91:CSharp/IntelligentBuilding.git ``` #### **步骤 2:解决 LFS Locking API 不支持的问题** ##### **方案 A:禁用 LFS 锁验证(临时方案)** ```bash # 针对当前仓库禁用 LFS 锁 git config lfs.http://lujuntao@192.168.1.91:8080/r/CSharp/IntelligentBuilding.git/info/lfs.locksverify false ``` > **注意**:此操作可能导致并行修改冲突,仅建议测试环境使用[^1]。 ##### **方案 B:升级 Git 服务器(根本方案)** 1. **GitLab 用户**:升级到最新版(需 ≥ 8.12)并启用 LFS: ```bash # 管理员登录 GitLab 执行 gitlab-rake gitlab:lfs:check ``` 2. **自建服务器**:确认已安装 `git-lfs` 并配置 `lfs.url`: ```bash git config -f /path/to/repo.git/config lfs.url http://your-git-server/lfs ``` ##### **方案 C:强制推送(慎用)** ```bash git lfs push --force origin main # 覆盖远程文件 ``` > **警告**:可能覆盖他人提交,仅限独占分支使用[^3]。 --- ### **验证修复** ```bash # 重新尝试推送 git lfs push origin main # 检查 LFS 状态 git lfs ls-files ``` --- ### **预防措施** 1. **正确初始化远程仓库**: ```bash # 首次添加 remote 时指定完整协议 git remote add origin http://user@git-server/repo.git ``` 2. **确认服务器支持 LFS**: ```bash curl -I http://git-server/version # 输出需包含 LFS 相关头信息(如 Git-LFS: ...) ``` 3. **配置全局 LFS 协议**(可选): ```bash git config --global lfs.https://your-server.locksverify false ``` --- **引用说明**: [^1]: 当服务器未实现 LFS 锁 API 时,禁用锁验证是常见解决方案。 [^3]: 强制推送可能引发提交覆盖,需协调团队协作规范。 若问题仍存在,请提供以下信息: 1. `git remote -v` 输出 2. Git 服务器类型及版本 3. `git lfs env` 完整输出 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值