[技术总结] 多设备代码同步问题，目前有比较好的解决办法么？

"保存工作区的内容 电脑上做了一半的任务，一般是 stash 后下次接着做，但 stash 的内容并不会同步到远程分支上，所以不能用 stash 命令来同步。" 这个我觉得转变思路就好，做了一半也可以提交 commit 啊

@Kahnn 接下来的后面半句 “也可以将做了一半的任务 push 到远程仓库的 WIP 分支中” 就是这个意思。

icloud

ssh 到一台机器上去写

git flow 中 feature 没到 pr 前不要每天 commit 多个.隔几天再 pr..依赖更新最新的分支后会处理冲突都老半天
如今微服务年代..调试服务的 rpc 脚本.导入数据.改 bug 重现.各种服务加起来.数据库.消息队列.定时器各种.
本地电脑起完还是很累的..
单个服务调试.用跳板机连线上测试服微服务..然后本地调试自己的模块服务 bug.
但是这种难免会写一些脚本.这种代码在两台电脑同步就纠结了.我一般代码会写在 dist 然后打包 icloud.同步.
复杂的就自己服务器跑一套完整的流程.传自己的 git.改代码 bug.打 log 提交.然后 webhook 全部服务自动重启.打 log 看看错误..留意自己服务器安全就好.一般偷偷摸摸..然后改完的代码..在对比复制到公司的代码库.提交就好..神不知鬼不觉..这样改 bug 效率会高很多.也不扯犊子占用测试服务器.也不干扰其它同事..如果公司 git 日志看到一堆 debug 提交记录.不知道会不会被骂死...vscode 的 web 服务器版本也是不错的.未来趋势发展.
今天累想划水带 MacBook12 寸.写服务端代码 (出门旅游.回老家带 12 寸+手机 4g 网络)
有心情加班带 MacBook15 寸高配主力+再写点前端代码
能迁移到自己服务器编写的都远程自己服务器..

projj 可以实现 开源项目

买一台 12 寸 MacBook 工作机随身带

都放 onedrive 不知行不行，自己日常需要多设备的文件基本都放在 onedrive 上

没有优雅的办法，.git 文件夹同步，想想就恐怖

随身携带个 msata 组的 u 盘，解决多设备同步

问题 1. 多仓库批量同步

Makefile 不行吗？

哪那么多事，谁生产随管理

我就好奇是什么导致了这种需求。
同一个人，多台电脑，频繁切换。

我觉得实在不行，可以自己写脚本，用脚本来完成 pull push commit 之类的操作。脚本通过网盘同步，每次切换电脑前，执行一下批量提交；切换电脑后，执行一下批量更新。

@randyzhao 我这两天就正好有这样的需求，首先我是在 server 上开发，但是公司 server 有些小问题，比如三天两头挂或者下线维护，工具链不统一，一些服务和工具只有部分 server 可以访问，server 分布在全球网络状况不一样，特定的测试需要独占 server 被分配到其他 server 上等等。另外我在不同 server 上配置的环境也有一些区别，比如有的我配了完整的 VNC+VSCode，有的我配了 code-server，有的我配了 Emacs，有的我连 .vimrc 都没碰过，虽然我意识到问题之后在尽量做统一，不过不是三两天就能改的。有些工作也会在本地 Debian Desktop 上处理（然而 server 是 RHEL，并且使用的模式完全不同 ...）

第一，如果无法接受同步 .git 文件夹的话，那其实已经不是小项目了，就算没有 git 之类的东西，项目本身的文件数量也会造成不小的压力，所以并不完全是 .git 文件夹的问题。另外 git 有一个 pack 的特性（ https://git-scm.com/book/en/v2/Git-Internals-Packfiles ），可以把 .git 里面的 objects 打包成若干大文件，你看下你从 GitHub 上直接 clone 下的 repo，.git 文件夹下其实是没有几个文件的

第二，用过 git submodules 么？“一键批量 Push 和 Pull ”之类的根本不需要什么“新的工具”。虽然我觉得我不会选择 git submodules （所以这个例子只是描述类似的通用的方法）。Android 用了一套 Python 脚本叫 repo 做得更完善一点，虽然我觉得有点慢还依赖 Python 大概也是不会用的 - -

第三，一个 WIP 的 patch 不是必须 stash，也不是必须 commit，也不是只能放着不管——上面提到的 repo 工具提供了一个新思路，就是专门开一个 branch，把半成品 commit 上去，这个 branch 只有这一个 commit，只拿来当 （某种意义上） stash 的替代品，没有其他任何功能。这样就可以利用 Git 分布式 push 和 pull，当你迁移到另外一台机器上，pull & checkout，干活，完后 git commit --amend，push (这个需要 -f)，当然你觉得 push -f 不 clean 可以选择单独 commit，反正是专门的 branch 可以随便搞事，全 done 之后 squash 到一个 commit 就是。这是充分利用 git 的优势

第四，我觉得这个问题没有一个万能的方案，应该针对不同的情况具体分析。比如如果一个人不用 git 或者多种 VCS 混用，网盘的通用性就更有好处。我的很多私人数据一直是 syncthing 同步的，因为首先个人数据不止是软件项目，就算有一些很像软件项目，其实并不一定适合用 VCS 的方式来管理（比如 Word 文档和 Sketch 稿），所以我不能依赖 git 这一特定的系统，其次并不是所有的代码都会被 git 管理的，就算是 git 仓库，利用 git 做同步的优势其实也并不明显（特别是考虑到前段时间 GitHub 没有免费 private repo 的情况），另外 push pop 乃至于偶尔处理 conflict 都是额外的 overhead，网盘基本就是扔在那就不用管，至于同步速度之类的那是实现细节的问题，理念上来讲我觉得网盘还是占优的。

我自己还是遇到了一些问题，比如在家里用 desktop 改了东西想要立刻在 laptop 上面测试，syncthing 是没办法实时同步的。另外公司环境下是不能乱用软件的，尤其不能用第三方云服务。但是机器环境比我个人的还要复杂一点。我有一些替代方案：
NFS/sshfs/Samba，这个用好了可以很 versatile，首先家里 NFS 可以随时访问整个文件库这个大家都知道。我还会单独做一个共享用来放临时文件，包括一些 demo 啊截图啊之类的，这个还可以当 poor man's Airdrop 解决上面的实时性的问题（有实时性的需求一般都是需要额外操作的，git 和 Airdrop 都是，所以这个没有本质区别，还不依赖 Apple 的生(jiu)态(cai)圈）。
另外我还会把代码仓库在本地 mount 一份，这个可以直接在本地用 native 的方式操作远程文件（抽象真的是很神奇的东西）。在网络可以的条件下，对于中小型仓库而言性能的损失不明显（所以也是楼主问题的一个可能解决方案）。大仓库问题就比较大，就算开大缓存（这个会牺牲实时性，基本等于 read only 了） git status 都要半天，但是需要利用本地工具操作较多文件的时候还是有用的（比如里面有一堆的 pdf 或者 md 或者 office 文档，本地的阅读器是用着最顺手的）。
这个当然不局限于两台机器，所以你可以把做好的 test case，脚本或者 patch 放在里面，立马就可以在网络上任何机器上用。
在公司中心的代码仓库是限制 commit 的（我也没有用某台 server 做中心库），所以用上面说的开 branch 来替代 stash 的做法不是特别现实。我的解决方案是在 A 机器上改完之后本地 commit （不 push 也没法 push ），在 B 机器上把 A 机器的仓库地址添加为新的 remote，然后 git fetch A 机器的仓库，git cherry-pick FETCH_HEAD，更改就拉过来了。我觉得这个流程绝大多数人都用不到（一个中心库就能搞定），在我这确实解决了问题，所以说要根据自己需求定制。

@randyzhao 很普通的需求，实验室一台电脑，家里一台电脑，手上一台笔记本，三台电脑随时拿来码代码。

@secondwtq 大概这就是想引的玉吧，很感谢你的回复。git gc 命令之前我是真的不知道，如果可以先 gc 再用 syncthing 同步，应该可以解决小文件同步的问题。另外，本地 mount 一份远程代码库也是一个比较好的办法。

不知道我理解的对不对，
你可以写个脚本，放在工作目录下，遍历 git 仓库然后循环执行 git pull ？ 每次开发要离开或者关闭电脑的时候把代码 git push 到 WIP 分支中。
这样在另一台电脑上执行你的脚本，批量拉取一下，就可以继续之前的代码工作？

我是 TeamViewer 远程 , 只在一台上写,反正公司的电脑从来不关

@cht1995 我就是这么做的。所有的项目代码都建在 OneDrive 的控制的文件夹里（主要项目所有文件包括.git 里的超过 2G ）。而且开了 File On Demand。不过好像核心的目的不是为了多设备同步，而是为了备份。

毕竟速度再快，同步也是需要时间的。不太可能这台设备写了一些代码，然后马上换另一台设备就能立刻同步到之前的更改。。。搞不好还是有文件内容冲突的风险。

所以，我觉得解决问题的根本方法，还是弄一台好笔记本电脑配上合适的附件吧。我就是一台 Surface Book 2，公司和家里各配上 Surface 拓展坞 + 2 台显示器，然后外面用 SB2，家里和办公室只需要把 SB2 插上拓展坞就行了，永无同步之忧。

把一台电脑当 server，其他电脑远程连上去，如用 VS Code Remote

nvme 固态外置硬盘。ide 和代码统统放硬盘上

一个 git 项目就行了吧。放到子文件夹里面。其实我搞 node 的时候，就用 lerna 组织代码，一个项目包含所有的。很难理解拆分一堆项目怎么想的。一个就够了。

git 的 submodule 也比较坑，很多工具不支持。

而且就算一个项目未来想要把某个子文件夹拆分出来给别人，也有 filter-branch 命令可以形成 repo

哪有那么多事，全放到 svn 一个 repo 里面，随时提交

自己用的是群晖 Cloud Station Drive，.git 文件夹都是完整上传的，自建 NAS 不像网盘，不用考虑空间容量的问题。
几个同步点都是电信网络，加之去年开始运营商的上行速度都放开了，传输非常快，NAS 优势非常明显。

兄弟们，你们可以尝试一下 git mirror 功能，绝对满足各位的需求，包括 USB，网盘同步。别在傻傻的复制整个工程。

git clone --mirror path/project

会生成一个干净的 path/mirror/project.git 文件夹，

git remote add local path/mirror/project.git
git fetch local
git push local
同步代码简单、方便、快捷。

https://myrepos.branchable.com/

mr register
mr update

啊我瞎

myrepos 的文档在上述网址，基本上全了
实质 Makefile，甚至有 $@ 这种东西……。

我也有一堆.git , 写个批处理完事, 全传 github

我有一个想法不知道能不能实现楼主的目的：git 和 SVN 结合。
所有的 git 项目都放在一个 svn 目录下，有需要发版本的，git 上该怎么操作就怎么操作。
如果像那种在一台电脑做了一半，想在另一台电脑接着做的，又不想 push 到 git 远程仓库的，那么这时候直接全量提交到 SVN，在另一台电脑上使用 SVN 拉取。

onedrive+1..
前公司经常干的事情, 其它方案实在太繁琐了.

这是要同步 git 仓库代码？ git hook 了解下

Vscode remote
Azure devops+git

欢迎体验 VSCode Remote

@Deardrops 我昨天半夜迷迷糊糊过了一遍主楼几个链接和一堆回复之后似乎就忘了顶楼提过试过 submodules 和 repo 之类的了，写回复的时候以为楼主没仔细了解过，抱歉。

关于顶楼提到的几个问题，submodules 没仔细了解过所以不好评价，但是 repo 我觉得还不错，文档缺失实际上是大多数开源项目的通病，就算是明星项目也很难保证文档是全的（更何况文档多了甚至会有人抱怨太 overwhelming 不知从何下手），冷门项目更难说，所以在看免费 /开源方案的时候就有必要做好 DIY 的准备。我个人觉得重要的是学习整个工作流的思想。另外一个适合自己的方案很多时候是拼出来的，如果 repo 能满足批量 push 和 pull 的功能，那其实就可以考虑把这一小部分集成进自己的工作流里面。按照“重新造一个新轮子”的逻辑执行，其实不一定比 battle tested 的旧轮子效果好。按照这个逻辑还可以推导出：Chrome 太占内存了重新造一个，python 性能太慢了重新造一个，cpu 太热了要不明天去海边整点沙子也自己造一个把 ...

单独开分支存放 WIP 内容确实会造成额外的操作，但是这个额外操作是能*换来*一点好处的。比如我上个回复提到的对实时性的控制：假设有一个理想化的方法，解决了网盘同步 .git 目录很麻烦的问题。现在我在 A 机器上改了一点东西，用网盘同步，然后（出于某种原因）立马切到 B 机器上，网盘可能不能做到立即同步，你得去轮询文件的同步状态 ... 但是通过 git 一通额外操作，是可以让你确定同步完成的。在用脚本做了一定的自动化之后可能就是一个命令的事，最后对用户的负担可能还要比用网盘同步然后轮询状态更小。

因为物理法则限制，没有网盘能做到立即同步，而如果要在一个特定的时间要求特定的一部分文件做到优先同步并且以某种方式通知之类的需求，用户依然得 somehow 把这个需求描述给计算机，这就是那些“额外操作”。

这里有一个问题就是，git 这个东西并非完全针对楼主的使用场景设计，它设计的这些额外操作其实在多人协作分布式开发开源软件（或者说就是 Linux Kernel ）的场景下才能做到最大的效率提升。所以楼主觉得麻烦，因为这个脚和鞋的尺码对不上。我个人的思路是可以考虑针对这一点做改进和增强，比如做一个脚本，把所有 unstaged/cached changes commit 到 WIP 分支，然后 push，写个编辑器插件，保存的时候自动运行，每台机器在打开项目的时候自动 pull。这个东西就是专门定制的，比如就没有考虑多人开发，如果把这个强行套到多人开发，只要出个 conflict，处理过程会比手动处理更麻烦，是没有带来方便的。

大致意思是最好不要期待有现成的方案，确实有不少，但是就像楼主说的有这样那样的问题，没有万能的。就算真有，哪天换个公司，换个条件，场景又变了，可能就没那么有用了

另外 VSCode Remote 是不开源的。我个人虽然反对逢微软就反，但是这个事情依然给我一种微软把 VSCode 开源拿来钓鱼，鱼上钩了就给你套回闭源环境的感觉

客观来讲 VSCode 似乎被大家广泛黑的只有 Electron 一个黑点（除了是微软出的这种无理取闹以外），并且我觉得这不是 VSCode 的原罪。所以其实这个饵还是下了血本的，然而依然改变不了钓鱼的本质

VSCode 这个饵我吃了，该占的便宜要占。Remote ？抱歉，坚决不上钩

话说 VSCode 图标就是俩圈，真的挺适合挂钩上的

vs code remote 可能会成为开发趋势，特别是省掉大量环境配置问题，不过养个 vs code remote 硬件可能要花费不少

我的项目里也是一堆包，一个前端项目能分 7 8 个 npm 包，烦死人的，现在是简单手写的个 python 搞了一下，我的目录是这个

├── updateReps.py
├── rep1
├── rep2
├── rep3
├── rep4
├── rep5
└── rep6


每次跑下 python3 ./updateReps.py 这样
```python
import os
from os import path

git_dirs = [
"rep1",
"rep2",
"rep3",
"rep4",
]


class bcolors:
HEADER = '\033[95m'
OKBLUE = '\033[94m'
OKGREEN = '\033[92m'
WARNING = '\033[93m'
FAIL = '\033[91m'
ENDC = '\033[0m'
BOLD = '\033[1m'
UNDERLINE = '\033[4m'

def printGreen( str ):
print(bcolors.OKGREEN + str + bcolors.ENDC)

cur_dir = path.dirname(path.abspath(__file__))


if __name__ == "__main__":
for git_dir in git_dirs:
git_dir_path = path.join(cur_dir, git_dir)
if os.path.isdir(git_dir_path):
os.chdir(git_dir_path)
printGreen('[run] [git pull] in ' + git_dir_path)
os.system("git pull")

print('-------------------------')
printGreen('finished')

```

学习，这个帖能让人少走很多弯路

直接做成一个大 git repo。
理由：你有这个需求吗：每个小仓库要分别控制是否都同步？比如今晚 2 个仓库都有代码改动，但是 repo A 需要同步 而 repo B 不同步？
如果有，那如何用「一次性」实现？要知道这个规则是动态的，你原来传统的方式是 git 分别 push，哪个 push 哪个不 push 是随时有变动的，一次性根本实现不了（因为每次的规则都不一样。如果你每次把规则定义好，那么工作量和你原来的传统方式基本上没区别。）
如果没有，那就是统一同步了，为何要分多 repo ？
所以比较好的方法是直接单 repo。

直接单 repo,很多大公司也是这么搞的。还有相应的工具。比如 ms 的 rush，可以用在多 project，单一 repo 的前后端合成的环境中。

看了这么多楼没有提 worktree 的，我现在的方案就是 nfs + worktree （ nfs 可以换成任意可靠的自动同步工具），前者解决“在本地和远程上同时编辑和运行同一份代码“的问题，后者解决”本地和远程开发不同分支”的问题。

例如，我现在本地写得差不多，准备发布一个版本，那我需要 checkout 一个 release 分支出来，在开发服务器上做一些 pre release 的测试，这个过程中，我是很有可能发现问题，又返回去修改一些代码，再反复在本地和远程测试的，那我就可以从 .git 里 用 git worktree 命令，把这个 release 分支放在 nfs 下，这样本地和远程就自动同步了。这种需求下，**你往往需要同步的只是是 checkout 出来的这份代码，而不是整个 .git 目录**，而 worktree 正好避免了同步整个 .git 目录，你放在 nfs/sshfs/网盘上放的一切都正好是你需要同步的所有文件，不多也不少。

而你用 git 本身去解决这件事就很麻烦，首先你很难处理 unstaged files，因为一部分你暂时并不想提交上去，一部分却是需要马上同步的，而 git 提供的最小同步粒度一般就是 commit 而不是 file，你用 commit 和 stash 去模拟 file level 的同步，就一定会比 nfs rsync 网盘这些别扭，人家就是专业干这个的。而且 git 你至少需要手动 push fetch，如果你经常有这种远程调试的需求就知道这种手动同步有多恶心了，本来从逻辑上讲，虽然有多个机器，但只有你自己一个人在动代码，那自然就是最新的更改直接自动覆盖过去就好了。用这些工具同步 repo 的唯一问题是你并不想把.git 目录传来传去，那 worktree 出来解决了。

也许有些人对 git worktree 不熟，补充一下它的特性，就是说你一台机器只有一个真正的.git 目录，当你 git worktree add 把一个分支放到一个新路径下的时候，你会发现新路径下的.git 不再是一个包含所有版本信息的.git 目录，而是一个单文本文件，这个文本文件你放上去同步就几乎没有任何 overhead 了，而且你 cat 一下就知道这个文件内容是什么意思了。远程不要动它就可以了。

你这个是属于个人多台设备的同步，跟 git、svn 等 SCM 没有任何关系。SCM 主要功能是版本控制，其次是多人协同。你用 git 非但解决不了你的问题，反而污染 git 提交历史。

你这种情况“文件夹同步”或“挂载到本地的云存储”也解决不了，就算你能找到方法解决 .git 文件夹的同步，但本地开发环境总会遇到“绝对路径”的，你很难保证多份本地开发环境完全一摸一样。而且，对于持久性的工作来说，CPU、内存等硬件配置的微笑不同都会让人很难受。

你需要的是云上的个人主机，现在这东西还没做出来。当然我比较好奇的是，你都用笔记本编码了，为什么不全部在笔记本上工作。如果是笔记本太烂，就换一个好点的。

seafile 可以设置 ignore 列表

自己买个服务器建个私有 gitlab 啊，stash 的内容提交推送吧