"git init"와 "git init --bare"의 차이점은 무엇입니까?

"git init"와 "git init --bare"의 차이점은 무엇입니까?

---

사이에 다른 무엇 git init과 git init --bare? --bareGit 서버에 많은 블로그 게시물이 필요하다는 것을 알았습니다 .

에서 man 페이지 , 그것은 말했다 :

--bare

Bare 저장소를 작성하십시오. GIT_DIR 환경이 설정되지 않은 경우 현재 작업 디렉토리로 설정됩니다.

그러나 실제로 무엇을 의미합니까? 그것은 가질 필요가 --bare망할 놈의 서버 설정을 위해?

---

비 Bare Git Repo

이 변형은 작업 디렉토리가있는 저장소를 작성하므로 실제로 작업 할 수 있습니다 ( git clone). 그것을 만든 후에는 디렉토리에 히스토리와 모든 git 배관이 진행되는 .git 폴더가 포함되어 있음을 알 수 있습니다. .git 폴더가있는 레벨에서 작업합니다.

베어 깃 레포

다른 변형은 작업 디렉토리 ( git clone --bare) 없이 리포지토리를 만듭니다 . 작업 할 수있는 디렉토리가 없습니다. 디렉토리의 모든 것은 이제 위의 경우 .git 폴더에 포함 된 것입니다.

왜 하나를 사용 하는가?

작업 디렉토리없이 git repos가 필요하면 분기를 푸시 할 수 있고 누군가가 작업중 인 것을 관리하지 않는다는 것입니다. 베어되지 않은 저장소로 계속 푸시 할 수 있지만 누군가 작업중인 디렉토리에서 작업중인 브랜치를 잠재적으로 이동할 수 있으므로 거부됩니다.

따라서 작업 폴더가없는 프로젝트에서는 git가 저장 한 오브젝트 만 볼 수 있습니다. 그것들은 압축되고 직렬화되어 컨텐츠의 SHA1 (해시)하에 저장됩니다. Bare 저장소에 오브젝트를 가져 오려면 git show보고자하는 오브젝트의 sha1을 지정해야합니다. 프로젝트 모양과 같은 구조는 보이지 않습니다.

베어 리포지토리는 일반적으로 모든 사람이 작업을 수행하는 중앙 리포지토리입니다. 실제 작업을 조작 할 필요가 없습니다. 여러 사람의 노력을 동기화하는 방법입니다. 프로젝트 파일을 직접 볼 수 없습니다.

프로젝트에서 작업하는 유일한 사람이거나 "논리적 중앙"리포지토리를 원하지 않거나 필요로하지 않으면 베어 리포지토리가 필요하지 않을 수 있습니다. 하나는 선호 git pull 에서 이 경우에 다른 저장소. 이것은 베어가 아닌 리포지토리로 푸시 할 때 git의 반대 의견을 피합니다.

도움이 되었기를 바랍니다

---

짧은 답변

Bare 저장소는 작업 사본이없는 git 저장소이므로 .git의 컨텐츠는 해당 디렉토리의 최상위 레벨입니다.

Bare 이외의 저장소를 사용하여 로컬로 작업하고 Bare 저장소를 중앙 서버 / 허브로 변경하여 다른 사람과 변경 사항을 공유하십시오. 예를 들어 github.com에 리포지토리를 생성하면 베어 리포지토리로 생성됩니다.

따라서 컴퓨터에서 :

git init
touch README
git add README
git commit -m "initial commit"

서버에서 :

cd /srv/git/project
git init --bare

그런 다음 클라이언트에서 다음을 누릅니다.

git push username@server:/srv/git/project master

그런 다음 리모컨으로 입력하여 입력 내용을 저장할 수 있습니다.

서버 측의 저장소는 파일을 편집 한 다음 서버 시스템에서 커밋하는 것이 아니라 pull and push를 통해 커밋을 수행하므로 베어 리포지토리입니다.

세부

베어 리포지토리가 아닌 리포지토리로 푸시 할 수 있으며 git은 .git 리포지토리가 있음을 알지만 대부분의 "허브"리포지토리에는 작업 복사본이 필요하지 않으므로 베어 리포지토리를 사용하는 것이 일반적입니다. 이런 종류의 리포지토리에 작업 복사본이 없어도 무방하므로 권장됩니다.

그러나 베어 저장소가 아닌 저장소로 푸시하면 작업 복사본이 일관성이 없으며 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'.

이 경고를 건너 뛸 수 있습니다. 그러나 권장되는 설정은 Bare가 아닌 저장소를 사용하여 로컬로 작업하고 Bare 저장소를 허브 또는 중앙 서버로 밀어서 가져 오는 것입니다.

If you want to share work directly with other developer's working copy, you can pull from each other repositories instead of pushing.

---

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.

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).

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 --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.

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:

---

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.

---

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.

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.

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.

When you clone from a server Git has all the information it needs in the .git directory to create your working copy.

---

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 track are stored. On the other hand, Working Tree keeps all commits forever. See below...

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.

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.

(The texts 'first', 'second', 'third', 'fourth', 'alpha', 'beta' and 'delta' are the commit comments. The names 'master' and 'greek' are branch names.)

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:

The git-bare repository deletes both the branch and all referenced comits. In the picture we see that its tree was reduced for this reason.

On the other hand, the git-working-tree repository, 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.

IN BRIEF: Commits are never dropped in working-tree repositories, but are deleted in bare repositories.

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 bare repository 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

참고URL : https://stackoverflow.com/questions/7861184/what-is-the-difference-between-git-init-and-git-init-bare