使用git clone --single-branch克隆的仓库向原远程推送是否安全？

1. 推送修改回原远程仓库是否安全？ #

完全安全。git clone --single-branch只是限制克隆时仅拉取指定分支的历史记录，并不会改变本地仓库的Git核心机制——它本质上还是一个标准的Git仓库，拥有完整的Git功能。只要你拥有原远程仓库的推送权限，推送操作和普通克隆的仓库没有任何区别，不会破坏远程仓库的历史数据。

2. 推送新分支耗时久的原因 #

你感觉到的“推送整个分支历史”，大概率是因为--single-branch克隆的仓库默认只跟踪了原分支，本地没有获取远程仓库的其他分支引用或关联对象。当推送新分支时，Git需要校验新分支上所有提交对象在远程仓库的存在性，过程中会同步一些之前未拉取的元数据，但实际上并不会重复推送远程已有的历史对象。如果你的新分支是基于原分支创建的，推送的仅仅是你新增的提交，只是校验过程可能让你产生“推送全量历史”的错觉。

3. Gitlab分支图着色异常的解释 #

这是Gitlab分支可视化的逻辑问题，而非仓库历史本身错误。Gitlab的分支颜色是基于最新提交所属分支来分配的：你的新分支拥有最新的提交，所以它的整条历史线会被标记为新分支的颜色；而原分支因为没有新提交，在可视化图中看起来像是从新分支分出的。但实际上仓库的提交历史是正确的，你可以通过git log --graph --oneline在本地查看完整的分支拓扑，确认历史合并没有问题。

4. 存储量翻倍的疑问 #

Git的存储是基于内容寻址的对象系统，同一个提交、文件对象只会存储一次，不会因为新增分支而重复存储历史数据。所谓“存储量翻倍”更可能是以下情况：

• Gitlab的存储统计包含了临时缓存、LFS对象、或者分支/标签的引用数据，这些不会占用大量空间；
• 你可能误操作修改了原分支的历史（比如rebase），导致远程仓库需要保留旧的历史对象（Git会自动清理未引用的对象，但有延迟）；
• 单纯是视觉错觉，建议在Gitlab项目的「设置-存储」中查看详细的存储占用 breakdown，或者在本地执行git count-objects -v查看本地仓库的对象大小，确认是否真的存在重复存储。

内容的提问来源于stack exchange，提问作者bartoli