“git init”和“git init --bare”有什么区别?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/7861184/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the difference between "git init" and "git init --bare"?
提问by Kit Ho
What is the different between git init
and git init --bare
? I found that a lot of blog post requires --bare
for their Git server?
git init
和之间有什么区别git init --bare
?我发现很多博客文章需要--bare
他们的 Git 服务器?
From the man page, it said:
从手册页,它说:
--bare
Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory
--bare
创建一个裸仓库。如果没有设置 GIT_DIR 环境,则设置为当前工作目录
But what does it actually mean? Is it required to have --bare
for the Git server setup?
但它实际上意味着什么?--bare
Git服务器设置是否需要?
采纳答案by Adam Dymitruk
Non-Bare Git Repo
非裸 Git 存储库
This variant creates a repository with a working directory so you can actually work (git clone
). After creating it you will see that the directory contains a .git folder where the history and all the git plumbing goes. You work at the level where the .git folder is.
此变体创建一个带有工作目录的存储库,以便您可以实际工作 ( git clone
)。创建后,您将看到该目录包含一个 .git 文件夹,其中包含历史记录和所有 git 管道。您在 .git 文件夹所在的级别工作。
Bare Git Repo
裸 Git 存储库
The other variant creates a repository without a working directory (git clone --bare
). You don't get a directory where you can work. Everything in the directory is now what was contained in the .git folder in the above case.
另一个变体创建一个没有工作目录 ( git clone --bare
)的存储库。您没有获得可以工作的目录。在上述情况下,目录中的所有内容现在都包含在 .git 文件夹中。
Why You Would Use One vs. the Other
为什么你会使用一个与另一个
The need for git repos without a working directory is the fact that you can push branches to it and it doesn't manage what someone is working on. You still can push to a repository that's not bare, but you will get rejected as you can potentially move a branch that someone is working on in that working directory.
没有工作目录的 git repos 的需要是这样一个事实,即您可以将分支推送到它并且它不管理某人正在处理的内容。您仍然可以推送到非裸的存储库,但您将被拒绝,因为您可能会移动某个人正在该工作目录中工作的分支。
So in a project with no working folder, you can only see the objects as git stores them. They are compressed and serialized and stored under the SHA1 (a hash) of their contents. In order to get an object in a bare repository, you need to git show
and then specify the sha1 of the object you want to see. You won't see a structure like what your project looks like.
因此,在没有工作文件夹的项目中,您只能看到 git 存储的对象。它们被压缩和序列化并存储在其内容的 SHA1(哈希)下。为了在裸存储库中获取对象,您需要git show
然后指定要查看的对象的 sha1。您不会看到与您的项目类似的结构。
Bare repositories are usually central repositories where everyone moves their work to. There is no need to manipulate the actual work. It's a way to synchronize efforts between multiple people. You will not be able to directly see your project files.
裸存储库通常是每个人都将工作转移到的中央存储库。无需操纵实际工作。这是在多人之间同步努力的一种方式。您将无法直接看到您的项目文件。
You may not have the need for any bare repositories if you are the only one working on the project or you don't want/need a "logically central" repository. One would prefer git pull
fromthe other repositories in that case. This avoids the objections that git has when pushing to non-bare repositories.
如果您是该项目的唯一工作人员,或者您不想要/不需要“逻辑中央”存储库,则您可能不需要任何裸存储库。一个宁愿git pull
从在这种情况下,其他存储库。这避免了 git 在推送到非裸存储库时的反对意见。
Hope this helps
希望这可以帮助
回答by duncan
Short answer
简答
A bare repository is a git repository without a working copy, therefore the content of .git is top-level for that directory.
裸仓库是没有工作副本的 git 仓库,因此 .git 的内容是该目录的顶级内容。
Use a non-bare repository to work locally and a bare repository as a central server/hub to share your changes with other people. For example, when you create a repository on github.com, it is created as a bare repository.
使用非裸存储库在本地工作,使用裸存储库作为中央服务器/集线器与其他人共享您的更改。例如,当您在 github.com 上创建存储库时,它被创建为裸存储库。
So, in your computer:
因此,在您的计算机中:
git init
touch README
git add README
git commit -m "initial commit"
on the server:
在服务器上:
cd /srv/git/project
git init --bare
Then on the client, you push:
然后在客户端,你推送:
git push username@server:/srv/git/project master
You can then save yourself the typing by adding it as a remote.
然后,您可以通过将其添加为遥控器来保存自己的输入。
The repository on the server side is going to get commits via pull and push, and not by you editing files and then commiting them in the server machine, therefore it is a bare repository.
服务器端的存储库将通过拉取和推送获得提交,而不是通过您编辑文件然后在服务器机器中提交它们,因此它是一个裸存储库。
Details
细节
You can push to a repository that is not a bare repository, and git will find out that there is a .git repository there, but as most "hub" repositories do not need a working copy, it is normal to use a bare repository for it and recommended as there is no point in having a working copy in this kind of repositories.
你可以推送到一个不是裸仓库的仓库,git 会发现那里有一个 .git 仓库,但是由于大多数“集线器”仓库不需要工作副本,所以使用裸仓库是正常的它并被推荐,因为在这种存储库中拥有工作副本是没有意义的。
However, if you push to a non bare repository, you are making the working copy inconsistent, and git will warn you:
但是,如果您推送到非裸存储库,则会导致工作副本不一致,并且 git 会警告您:
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
You can skip this warning. But the recommended setup is: use a non-bare repository to work locally and a bare repository as a hub or central server to push and pull from.
您可以跳过此警告。但推荐的设置是:使用非裸存储库在本地工作,使用裸存储库作为集线器或中央服务器进行推送和拉取。
If you want to share work directly with other developer's working copy, you can pull from each other repositories instead of pushing.
如果您想直接与其他开发人员的工作副本共享工作,您可以从彼此的存储库中拉取而不是推送。
回答by Salvador Dali
When I read this question some time ago, everything was confusing to me. I just started to use git and there are these working copies (which meant nothing at that time). I will try to explain this from perspective of the guy, who just started git with no idea about terminology.
当我前段时间读到这个问题时,一切都让我感到困惑。我刚开始使用 git 并且有这些工作副本(当时没有任何意义)。我将尝试从这个人的角度来解释这一点,他刚开始使用 git,对术语一无所知。
A nice example of the differences can be described in the following way:
可以通过以下方式描述差异的一个很好的例子:
--bare
gives you just a storage place (you can not develop there). Without --bare
it gives you ability to develop there (and have a storage place).
--bare
给你一个存储的地方(你不能在那里开发)。没有--bare
它,您就可以在那里开发(并有一个存储空间)。
git init
creates a git repository from your current directory. It adds .git folder inside of it and makes it possible to start your revision history.
git init
从当前目录创建一个 git 存储库。它在其中添加了 .git 文件夹,并可以开始您的修订历史记录。
git init --bare
also creates a repository, but it does not have the working directory. This means that you can not edit files, commit your changes, add new files in that repository.
git init --bare
还创建了一个存储库,但它没有工作目录。这意味着您不能在该存储库中编辑文件、提交更改、添加新文件。
When --bare
can be helpful?You and few other guys are working on the project and use git . You hosted the project on some server (amazon ec2
). Each of you have your own machine and you push your code on ec2
. None of you actually develop anything on ec2
(you use your machines) - you just push your code. So your ec2
is just a storage for all your code and should be created as --bare
and all your machines without --bare
(most probably just one, and other will just clone everything). The workflow looks like this:
什么时候--bare
能帮上忙?您和其他几个人正在从事该项目并使用 git 。您将项目托管在某个服务器 ( amazon ec2
) 上。你们每个人都有自己的机器,然后将代码推送到ec2
. 你们没有人实际开发任何东西ec2
(你使用你的机器)——你只是推送你的代码。所以你ec2
只是一个存储你所有代码的地方,应该像--bare
你的所有机器一样创建--bare
(很可能只有一个,其他机器只会克隆所有东西)。工作流程如下所示:
回答by Sandro Munda
A default Git repository assumes that you will be using it as your working directory. Typically, when you are on a server, you have no need to have a working directory. Just the repository. In this case, you should use the --bare
option.
默认的 Git 存储库假定您将使用它作为您的工作目录。通常,当您在服务器上时,您不需要有工作目录。只是存储库。在这种情况下,您应该使用该--bare
选项。
回答by Andrew
A non-bare repository is the default. It is what is created when you run git init
, or what you get when you clone (without the bare
option) from a server.
非裸存储库是默认的。它是您运行时创建的内容git init
,或者是您bare
从服务器克隆(无选项)时获得的内容。
When you work with a repository like this, you can see and edit all of the files that are in the repository. When you interact with the repository - for example by committing a change - Git stores your changes in a hidden directory called .git
.
当您使用这样的存储库时,您可以查看和编辑存储库中的所有文件。当您与存储库交互时(例如通过提交更改),Git 将您的更改存储在名为 .gitignore 的隐藏目录中.git
。
When you have a git server there is no need for there to be working copies of the files. All you need is the Git data that's stored in .git
. A bare repository is exactly the .git
directory, without a working area for modifying and committing files.
当你有一个 git 服务器时,就不需要文件的工作副本。您所需要的只是存储在 .git 文件中的 Git 数据.git
。裸仓库就是.git
目录,没有用于修改和提交文件的工作区。
When you clone from a server Git has all the information it needs in the .git
directory to create your working copy.
当您从服务器克隆时,Git 在.git
目录中拥有创建工作副本所需的所有信息。
回答by Sergio Cabral
Another difference between --bare and Working Tree repositories is that in the first case no lost commits are stored, but only commits that belong to a branch trackare stored. On the other hand, Working Tree keeps all commits forever. See below...
--bare 和工作树存储库之间的另一个区别是,在第一种情况下,不会存储丢失的提交,但只存储属于分支轨道的提交。另一方面,工作树永远保持所有提交。见下文...
I created the first repository (name: git-bare) with git init --bare
. It's the server. It's on the left side, where there are no remote branches because this is the remote repository itself.
我创建了第一个存储库(名称:git-bare)git init --bare
。是服务器。它在左侧,没有远程分支,因为这是远程存储库本身。
I created the second repository (name: git-working-tree) with git clone
from the first. It's on the right. It has local branches linked to remote branches.
我使用第一个存储库创建了第二个存储库(名称:git-working-tree)git clone
。这是在右边。它具有链接到远程分支的本地分支。
(The texts 'first', 'second', 'third', 'fourth', 'alpha', 'beta' and 'delta' are the commit comments. The names 'master' and 'greek' are branch names.)
(文本“first”、“second”、“third”、“fourth”、“alpha”、“beta”和“delta”是提交注释。名称“master”和“greek”是分支名称。)
Now I will delete the branch named 'greek' both in git-bare(command: git push --delete origin greek
) and locally in git-working-tree(command: git branch -D greek
). Here's how the tree looks:
现在,我将在git-bare(命令:)git push --delete origin greek
和git-working-tree(命令:)中删除名为“greek”的分支git branch -D greek
。这是树的外观:
The git-barerepository deletes both the branch and all referenced comits. In the picture we see that its tree was reduced for this reason.
该混帐裸仓库同时删除分支和所有引用comits。在图片中,我们看到它的树因为这个原因而减少了。
On the other hand, the git-working-treerepository, which is equivalent to a commonly used local repository, does not delete commits, which can now only be referenced directly by your hash with a git checkout 7fa897b7
command. That is why its tree does not have its modified structure.
另一方面,git-working-tree存储库,相当于常用的本地存储库,不会删除提交,现在只能通过git checkout 7fa897b7
命令由您的哈希直接引用。这就是为什么它的树没有修改过的结构。
IN BRIEF: Commits are never dropped in working-treerepositories, but are deleted in barerepositories.
简而言之:提交永远不会在工作树存储库中删除,而是在裸存储库中删除。
In practical terms, you can only recover a deleted branch on the server if it exists in a local repository.
实际上,如果本地存储库中存在已删除的分支,则您只能恢复服务器上已删除的分支。
But it is very strange that the size of the barerepository does not decrease in disk size after deleting a remote branch. That is, the files are still there somehow.To dump the repository by deleting what is no longer referenced or what can never be referenced (the latter case) use the git gc --prune
command
但是很奇怪的是,删除远程分支后,裸仓库的大小并没有减少磁盘大小。也就是说,文件仍然以某种方式存在。要通过删除不再引用的内容或永远不会引用的内容(后一种情况)来转储存储库,请使用以下git gc --prune
命令