@
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，更改就拉过来了。我觉得这个流程绝大多数人都用不到（一个中心库就能搞定），在我这确实解决了问题，所以说要根据自己需求定制。