什么是裸仓库，为什么我需要仓库？ [英] What is a bare repository and why would I need one?

问题描述

这可能已被回答，但我没有找到一个好的答案。

我来自集中式存储库，例如SVN，通常您只执行签出，更新，提交，还原，合并并没有太多。

Git让我疯狂。有很多命令，但最难理解的是为什么许多事情都像他们一样工作。

根据什么是纯粹的git存储库？：

使用 git init --bare 被称为裸回购。它们的结构与工作目录有些不同。首先，它们不包含任何工作或已检出的源文件副本。

...

使用 git创建的裸存储库init --bare 用于... 共享。 ......开发人员将克隆共享裸回购，在其工作副本中进行本地更改，然后推回共享裸回购，以便将其更改提供给其他用户。

- Jon Saints， http://www.saintsjd.com/2011/01 / what-is-a-bare-git-repository /

然而，从接受的答案到github存储库和git裸存储库有什么区别？：

GitHub上的Git Repos是裸机的，就像您要推送到其中的任何远程回购 [sic] 。
- VonC， https://stackoverflow.com/a/20855207

但是，在GitHub中有源文件。我可以看到他们。如果我创建一个裸仓库，那么没有源文件，只有工作仓库的 .git 目录的内容。

这怎么可能？我不明白什么？

您能否举一个例子说明为什么我需要一个裸仓库及其动机以这种方式工作？

更新

爱德华汤姆森的答案部分是我想知道的。尽管如此，我还是会重申一下我的问题：

我发布的第一个链接状态（
$ b

$ b是一个裸的git仓库/ =nofollow noreferrer>什么是裸仓库仓库？ $ b

他们[裸存储库]不包含任何工作或检出的源文件副本。

VonC的答案： p>

GitHub上的Git仓库是裸机

声明暗示

Github没有工作副本。

Edward Thomson说：

它呈现基于网页在您浏览数据时 - 将数据直接从repo中拖出并发送到您的Web浏览器，而不是先将它写入文件服务器上的磁盘上

不知何故，这是一个裸仓库必须包含所有数据和源代码。如果没有，就不可能渲染任何东西，因为我可以看到所有的源代码更新（提交），所有分支（各自的源），整个日志回购等。

存储库中的所有数据是否总是位于.git目录中（或裸露的存储库中），以某种格式能够随时呈现所有文件？这是裸仓库的原因，而工作副本只有在给定时间的文件？

解决方案

存储库的整个数据总是在 .git内目录（或裸露的回购），以某种能够随时呈现所有文件的格式？

是的，这些文件及其完整历史记录存储在 .git / packed-refs 和 .git / refs 和

当您克隆回购（无论是否存在）时，您 总是包含 .git 文件夹（或一个文件夹，其中 .git 扩展名用于裸回购，命名约定）及其Git管理和控制文件。 （查看词汇表）

Git可以随时随时解包使用git unpack-objects 所需的东西。

诀窍是：

从裸仓库中，您可以查询日志（ git log 在git bare 回购中工作得很好：不需要工作树）或在裸露的资料库中列出文件。

或者显示文件的内容从裸露的repo 。
这就是GitHub如何使用文件呈现页面而不必检出完整的回购。

我不知道GitHub确实 ，尽管如此，由于回购势力的数量 GitHub工程团队进行各种优化。

参见他们如何优化克隆/获取回购协议。

通过 d Git ，那些裸回购实际上跨多个服务器复制。

这是裸仓库的原因，而工作副本只有在给定时间的文件？

对于GitHub，维护一个工作树会在磁盘空间中花费太多，并且在更新时（每个用户请求不同的分支时） 。一般来说（GitHub约束之外），一个裸回购是用来推送的，以避免工作树与刚推出的内容不同步。参见但为什么我需要一个裸回购？为具体的例子。

这就是说：

• 自 git 2.3，您可以推送到非裸回购商（即相应地更新工作树）


• 自 git 2.4以来，您可以推送 （即，它适用于尚未出生的分支）

但是GitHub不可能为每个必须存储的repo维护一个（或者服务器）工作树。

This maybe has been answered, but I didn't find a good answer.
I come from centralized repositories, such as SVN, where usually you only perform checkouts, updates, commits, reverts, merges and not much more.

Git is driving me crazy. There are tons of commands, but the most difficult to understand is why many things work as they do.

According to "What is a bare git repository?":

Repositories created with git init --bare are called bare repos. They are structured a bit differently from working directories. First off, they contain no working or checked out copy of your source files.
…
A bare repository created with git init --bare is for… sharing. …developers will clone the shared bare repo, make changes locally in their working copies of the repo, then push back to the shared bare repo to make their changes available to other users.
– Jon Saints, http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/

However, from the accepted answer to "what's the difference between github repository and git bare repository?":

Git repos on GitHub are bare, like any remote repo to which you want to push to [sic].
– VonC, https://stackoverflow.com/a/20855207

However, in GitHub there are source files. I can see them. If I create a bare repository, there are no source files, only the contents for .git directory of a working repository.

How is this possible? What don't I understand?

Can you give an example about why I would need a bare repository and its motivation to work that way?

UPDATE

Edward Thomson's answer is, in part, what I wanted to know. Nevertheless, I will rephrase my question:

First link I posted states("What is a bare git repository?"):

they [bare repositories] contain no working or checked out copy of your source files.

VonC's answer:

Git repos on GitHub are bare

Both statements implies

Github has no working copy.

Edward Thomson says:

it renders the web page based on the data as you navigate through it - pulling the data directly out of the repo and out to your web browser, not writing it to a disk on the fileserver first

Somehow, a bare repository has to contain all data and source code. If not, it wouldn't be impossible to render anything, because I can see all source code updated (commited), all branches (with their respective source), the whole log of a repo, etc.

Is there the whole data of a repository always within .git directory (or in a bare repo), in some kind of format which is able to render all files at any time? Is this the reason of bare repository, while working copy only has the files at a given time?

解决方案

Is there the whole data of a repository always within .git directory (or in a bare repo), in some kind of format which is able to render all files at any time?

Yes, those files and their complete history are stored in .git/packed-refs and .git/refs, and .git/objects.

When you clone a repo (bare or not), you always have the .git folder (or a folder with a .git extension for bare repo, by naming convention) with its Git administrative and control files. (see glossary)

Git can unpack at any time what it needs with git unpack-objects.

The trick is:

From a bare repo, you can query the logs (git log in a git bare repo works just fine: no need for a working tree), or list files in a bare repo.
Or show the content of a file from a bare repo.
That is how GitHub can render a page with files without having to checkout the full repo.

I don't know that GitHub does exactly that though, as the sheer number of repos forces GitHub engineering team to do all kind of optimization.
See for instance how they optimized cloning/fetching a repo.
With DGit, those bare repos are actually replicated across multiple servers.

Is this the reason of bare repository, while working copy only has the files at a given time?

For GitHub, maintaining a working tree would cost too much in disk space, and in update (when each user request a different branch). It is best to extract from the unique bare repo what you need to render a page.

In general (outside of GitHub constraint), a bare repo is used for pushing, in order to avoid having a working tree out of sync with what has just been pushed. See "but why do I need a bare repo?" for a concrete example.

That being said:

• since git 2.3 you could push to a non-bare repo (that would update the working tree accordingly)
• since git 2.4, you can "push-to-deploy" (ie, it works for unborn branch as well)

But that would not be possible for GitHub, which cannot maintain one (or server) working tree(s) for each repo it has to store.

这篇关于什么是裸仓库，为什么我需要仓库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！