简单的问题吧？就和我一起裸露在这里..
我通常使用 Git 来处理本地计算机上的文件。我喜欢这种方法，因为我可以稍后在共享驱动器上查看文件以供其他非 git 用户使用。这很棒，因为我可以删除本地目录中的文件（清理）并远程清理。我可以将所有额外的文件保留在远程目录中。这种行为就是为什么我不简单地rsync...
我遇到的唯一问题是处理打开的文件。 Git 会停止，pull或者reset当我遇到锁定的文件时，我需要更改。这真的是一场秀吗？我可能需要非常快速地取出文件，并发现寻找阻止进程的不相关的打开文件会适得其反。
你能帮助改进这个过程吗？
顺便说一句：如果时间戳已更改，则仅更新文件就足够了。但我只想更新已更改的文件，以便增量备份不会受到不利影响。
显然这并不常见，所以我不会推广它。不过好处对我来说还是有好处的。这使我能够快速本地访问本地文件，而不受网络故障的影响，并且基本上无缝发布到备份驱动器。我只需要经常签入并推动以确保更改得到备份。它可以与共享驱动器上的其他非 git 文件和用户很好地配合。 Rsync 的不足只是因为“清理”。如果不删除其他用户文件，我就无法--delete清理。手动清理听起来可能很小，但它确实是一个交易杀手，因为清理很容易出错并且需要测试。
答案1
并不是说没有解决方案（虽然我不知道它是什么），但是，vis。 “这肯定是一项常见任务”——可能不是，因为您将该工具用于非预期目的。
git是一个版本控制系统，而不是文件系统同步守护进程或其他东西。做 VCS 工作的人不会急于在服务器上更新东西，而不确保他们的更新已准备好（我们希望），因此他们不太可能因为它失败而烦恼，因为某些东西显然被忽略了（“我遇到我锁定了我需要更改的文件”——因此进行您需要的更改，然后提交）。
换句话说，大多数 git 用户可能希望这个问题没有解决办法——这是一个用户友好的功能。
答案2
最简单：无头保管箱。
最佳：网络文件共享（SMB 或 NFS）
大锤（可能并不理想）：Capistrano 部署风格。要点是你有一个目录结构：
---syncdirectory
|
-----current----symlink
| |
-----releases |
| |
-----releaseA--|
|
-----releaseB
|
-----releaseC
本质上，每次 git deploy 都会创建一个新的发布目录，然后符号链接会翻转到“当前”目录。您打开的文件不会受到影响（尽管此时对它们的更改将保留在 releaseB 中）。您可以删除早于 releaseC 的所有内容，并且您的目录始终是“新”版本。