并发的git拉到同一本地存储库 [英] concurrent git pulls to same local repository

问题描述

我负责维护Jenkins服务器的工作，基本上检查一些代码并构建它。目前，他们使用--depth 1和-b {branch}选项来执行git克隆，以尽快获得特定的代码分支。但是这样做仍然是浪费，因为即使只有很少的（如果有的话）更改，每次执行作业时都会检查新的副本（通过网络）。

相反，我想要做的是在构建机器上共享本地回购，这是我们远程回购的克隆。每个作业都会在特定分支上执行git pull，以引入远程回购中的任何更改，然后在开始构建之前将源树从回购复制到Jenkins工作区。

这是一个坏主意吗？

我担心的是可能会运行针对相同代码分支的不同作业同时，这可能会导致并发的git pull请求。

这会导致Git的元数据损坏吗？

由于锁定问题，其中一个并发拉动可能失败吗？

共享本地回购将永远不会有任何改变，并且不会将任何更改推送到远程回购。这将是只拉，可以这么说。所有的拉都来自同一个用户，所以不应该有任何文件许可问题。

一些谷歌搜索从4年前开始讨论这个讨论，但它并没有看起来并不确定：

http://git.661346.n2.nabble.com/concurrent-fetches-to-update-same-mirror-td5893458.html

解决方案

这是一个坏主意吗？

可以考虑以下情况。

假设Job1做了一个git pull并检出了最新的代码，并开始从本地git仓库复制到工作区。在这个特定的时刻，Job2做了一个git pull，并且在复制过程还在进行时拷贝了很少的文件（对于一个大型的存储库，我相信这是可能的）。在这种情况下，您可能会收到来自两个结帐的文件，这不是您想要的。请纠正我，如果在这种情况下错了。

虽然不是原始问题的一部分，但添加下面的内容对其他人可能有用。

因为，你已经清楚地提到你不会将任何东西提交给git，所以你不会遇到竞争条件。 b
$ b

提示：由于当前分支的提示位于
提示符后面，所以更新被拒绝。合并远程更改（例如' git pull'）

提示：在再次推送之前。

提示：有关详细信息，请参阅'git push --help'中的'关于快速转发的提示' b $ b孩子退出时值为1 -

如果你的工作在执行后检查几个文件到git中，你会遇到这个错误更新版本号，更新日志等）。当你从git检出一个特定的修订版，并且在版本库的同一分支中有新的签入并且当前作业试图提交更新的文件并且它发现git不在相同的时候，就会出现这个错误版本与它签出时的版本。

• 如果你没有提交任何回git，值得给它
  尝试，因为你可以节省空间/作业执行通过避免多次
  拉。
  
  


• 如果您提交任何内容，在多个作业中共享单个
  git存储库不是一个好主意。

I've been tasked with maintaining a Jenkins server with jobs that basically check out some code and build it. Currently they do a git clone using the "--depth 1" and "-b {branch}" options to get a specific code branch as quickly as possible. But this is still wasteful since a fresh copy is being checked out (over the network) every time a job executes, even if there are very few (if any) changes.

Instead, what I'd like to do is have a shared local repo on the build machine that's a clone of our remote repo. Each job would do a "git pull" on a specific branch to bring in any changes from the remote repo, then copy the source tree from the repo to its Jenkins workspace before starting the build.

Is this a bad idea?

What concerns me is the possibility that different jobs targeting the same code branch will be run simultaneously, which could result in concurrent "git pull" requests.

Could this result in corruption of Git's meta-data?

Is one of the concurrent pulls likely to fail due to locking issues?

The shared local repo would never have any changes committed to it and nothing would ever be pushed from it to the remote repo. It would be "pull only", so to speak. All the pulls would come from the same user, so there shouldn't be any file permission issues.

Some googling turned up this discussion from 4 years ago, but it doesn't seem conclusive:

http://git.661346.n2.nabble.com/concurrent-fetches-to-update-same-mirror-td5893458.html

解决方案

Is this a bad idea?
Can think of a following scenario.
Assuming Job1 did a git pull and checked out the latest code and started copying from the local git repository to the workspace. At this particular moment, Job2 did a git pull and few of the files got copied when the copy process was still going on (For a large repository, i believe it could be possible). In such cases, you might have files from both the checkouts, which is not something you want. Please correct me, if am wrong in this particular scenario.

Though not part of the original question, adding the below as it might be useful to others.
Since, you've mentioned clearly that you are not going to commit anything back to the git, you don't encounter the race condition.

"hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
child exited with value 1 - "

You'll encounter this error if your job, after the execution, checks in a few files into git (Update version number, changelog etc...). This error occurs when you have checked out a specific revision from git and there has been a fresh check-in in the same branch of the repository and the current job tries to commit the updated files and it finds that the git is not in the same version as it was when it checked out.

• If you are not committing anything back to git, its worth giving it a try as you can save space / job execution time by avoiding multiple pull.
  
• If you commit anything back, its not a good idea to share a single git repository across multiple jobs.

这篇关于并发的git拉到同一本地存储库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！