git 仓库同步到坚果云上后损坏了

[EscYezi]

前两天在家里的 windows 笔记本上git init --bare新建了一个仓库，然后把这个文件夹同步到了坚果云上，并且向这个仓库里 push 了一些代码。 昨天在公司的 mac 上用坚果云把这个文件夹同步下来然后git clone到本地，并向仓库 push 了一些代码，看坚果云同步结束合上电脑下班了。到这里为止都没发现什么异常。 今天在家用坚果云把仓库同步下来，本地 pull 发现报错了，具体错误信息没有记录下来，换了一个目录 clone 报错

D:\projects>git clone file:///D:/nutstore-sync/git/algorithm al2 -b main
Cloning into 'al2'...
remote: errorerror: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
: Could not read 757adde25527ab466f2d48f3ae71ca1464b6df1ffatal: early EOF

remote: fatal: Failed to traverse parents of commit d26c516d98ef670e228eae36363bd015056b1283
remote: aborting due to possible repository corruption on the remote side.
fatal: fetch-pack: invalid index-pack output

进到仓库里fsck了一下

D:\nutstore-sync\git\algorithm>git fsck --name-object
Checking object directories: 100% (256/256), done.
broken link from  commit d26c516d98ef670e228eae36363bd015056b1283 (refs/heads/main)
              to  commit 757adde25527ab466f2d48f3ae71ca1464b6df1f (refs/heads/main^)
broken link from    tree 07e1bf67bee247eb4db40fa135f705dd05fa8972 (refs/heads/main:src/xxx/xxxxx/algorithm/)
              to    tree 8e30aad2ed2800aeed6c801b4b94d8847deb323a (refs/heads/main:src/xxx/xxxxx/algorithm/foroffer/)
missing tree 8e30aad2ed2800aeed6c801b4b94d8847deb323a (refs/heads/main:src/xxx/xxxxx/algorithm/foroffer/)
dangling tree 0f705bbff03e60514e46a060c4d61684582a55db
dangling blob 39408c376bd54f576a653b79fd899f37452fe4af
dangling tree cf04f6b34931f215f460332cbd0029669b9c60da
dangling tree e3170836338f688d7bd1d12f85cde4ec7705cf6d
dangling commit f1180ef1b7f4e924ecfbfd71bf05f0cea5c53367
missing commit 757adde25527ab466f2d48f3ae71ca1464b6df1f (refs/heads/main^)

搜了半天，找到的恢复方法都是先要有一个完整的仓库，在此基础上对损坏的仓库进行修复。但是现在的情况相当于远程仓库损坏了，有最新提交的本地仓库又在公司的电脑上，想着也没多少修改，干脆把代码提到了 GitHub 上，以后直接从 GitHub 拉代码总不会出问题了吧。

有趣的是在搜索解决方案的时候发现了一段话:

This isn't much help but: do not store Git repos in Dropbox or any other sync services. Git isn't built to handle another program randomly locking and rewriting files while it's doing something else.

之前也有过把 git 仓库放在 OneDrive 上，不过只是 push，没有从上面 clone 过，也没有同步到多端 push 和 clone 过，现在看似乎要重新考虑一下这种方案的可行性了。不知道大家有没有出现过类似的问题？

[codehz]

建议用 git bundle 功能打包成单文件然后上传云存储

[nightwitch]

即使同步算法做的最好(个人认为)的 dropbox 也特意指出，在同步盘里放 git 仓库可能导致文件损坏。dropbox 的解决方案是用一个中间件 git-remote-dropbox 来链接 git 和 dropbox 。

[EscYezi]

@codehz #1 学到了

[dingwen07]

https://blog.jianguoyun.com/?p=2839

[omph]

具体是哪里不兼容的？

[nieyujiang]

所以为什么不直接一开始就用 github 之类的东西呢.

[EscYezi]

@nieyujiang #6 公司网络访问 GitHub 不太稳定，gitee 用来做 GitHub 的国内镜像，其他平台暂不考虑。如果 GitHub 可以正常访问一开始就不会考虑这个方案了🌚

[gxy2825]

试试 Coding

[secretman]

云存储一般不能存 git 项目啊，奇奇怪怪的问题老多了

[secretman]

当你有多个分支不断来回切换时，大量文件不一致时，你会发现云同步大概率就卡死了

[guochao]

git 会快速操作大量文件，并且涉及到 filemode 一类的文件属性的操作，同步盘本质是把文件内容修改排队上传，定期 squash，有意外情况的时候（比如说在很短时间内增减同一个路径上的文件）很容易破坏 git 树，而且无法保留 filemode 也会丢失非常多信息。类似的是 vim，也会快速的增删文件

直接提交到 git{hub,lab,ee}吧，gitlab 在国内也建了团队，gitee 和 gitlab 在国内的可用性应该都会相对越来越好

[fengjianxinghun]

@guochao github 不可能好，gitlab 国区特供才可能好。

[FrankHB]

公司穷到连自建 GitLab 实例都负担不起的话直接 Gitee 吧。

[EscYezi]

@FrankHB 倒不是公司没有自建仓库，自己的一些东西没法传到公司仓库里

[tomkliyes]

@EscYezi 自己在 gitee 上建个私有仓库吧……人生苦短，不要花太多时间在这种事情上面……当然如果你本身就是做云存储相关的工作就当我没说

[hanssx]

@EscYezi 老哥最后怎么解决的，如果自建 gitlab 或者用 gitee 的话，如果代码仓库多了，怎么管理自动同步呢？

[hanssx]

@codehz 怎么管理大量 repo 呢
@nightwitch 也就是说 dropbox 可能有问题吧
@guochao 使用 gitee 怎么管理大量 repo 呢

[codehz]

@hanssx 大量就用正经的源码托管网站，别用网盘

[hanssx]

@codehz 我现在的方案是用网盘同步代码的时候把.git 屏蔽掉（不同步.git 文件夹），只在公司使用 git 做版本控制，目前没发现啥问题。

[EscYezi]

@hanssx #16 git bundle 用坚果云同步，写两个小脚本对 bundle push/pull