问题描述
有两种情况，我感兴趣。- 存储库是共享的，两个用户希望在同时
- 我想使用cron作业安排每晚或每周gc。它在运行期间运行，并且有人想要在操作期间推送或克隆。
在这两种情况下是否存在腐败风险？ p>
Git允许使用。
必要时，git会创建一些特殊文件来充当锁。
特别是，每次操作修改索引时，git都会在 .git 中创建一个名为 index.lock 的文件c $ c>目录来锁定共享资源。 Git会根据需要创建其他锁文件：例如，在操作。
一般来说，您不应该担心使用git的并发操作：它经过精心设计以支持他们。
有人可以告诉你不应该担心用cron作业来执行 gc ，因为git本身会触发不时有 gc 。即使这是真的，本身也建议：
鼓励用户定期在每个存储库中运行此任务
，以保持良好的磁盘空间利用率
和良好的操作性能。
因此，我认为安排工作任务来运行git的垃圾回收并不是一个坏主意。我只是想知道这是否是一个过早的优化，或者如果你正在试图解决一个真实的，有问题的问题。我个人从来没有遇到过要求我手动运行 gc 的问题，但如果您的情况非常不同，我不会感到惊讶。
There are two scenarios that I'm interested in.
- The repository is shared and two users want to push changes to it at the same time
- I want to schedule a nightly or weekly "gc" using a cron job. It runs and someone wants to push or clone during the operation.
Is there a risk of corruption in either of these scenarios?
Git allows concurrent operations by using a Pessimistic Concurrency Control.
When necessary, git creates some special files to act as locks.
In particular, every time the index is modified by an operation, git creates a file called index.lock in the .git directory to lock the shared resource. Git creates at needs other lock files: for example, a .keep file is created during git index-pack operations.
In general, you shouldn't worry about concurrent operations with git: it is carefully designed to support them.
Someone could tell you shouldn't worry about performing gc with a cron job, since git itself triggers gc from time to time. Even if this is true, the man page itself recommends:
Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance.
Hence, I think it's not a bad idea to schedule a job task to run git's garbage collection. I just wonder if it is a premature optimisation or if you are trying to solve a real, measured issue. I personally haven't ever had problems that required me to manually run gc, but I wouldn't be surprised if your case is pretty different.
这篇关于使用Git存储库可以执行并发操作吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！