間の異なる何であるgit initとはgit init --bare？多くのブログ投稿が--bareGitサーバーに必要であることを発見しましたか？

マニュアルページから、それは言った：

--bare

ベアリポジトリを作成します。GIT_DIR環境が設定されていない場合、現在の作業ディレクトリに設定されます

しかし、それは実際にはどういう意味ですか？--bareGitサーバーのセットアップに必要ですか？

非ベアGitリポジトリ

このバリアントは、実際に作業できるように、作業ディレクトリを持つリポジトリを作成します（git clone）。それを作成した後、ディレクトリには履歴とすべてのgit配管が行われる.gitフォルダーが含まれていることがわかります。.gitフォルダーがあるレベルで作業します。

ベアGitレポ

もう1つのバリアントは、作業ディレクトリなしでリポジトリを作成します（git clone --bare）。作業できるディレクトリがありません。上記の場合、ディレクトリ内のすべてが.gitフォルダーに含まれていたものになります。

どちらを使用するのか

作業ディレクトリなしでgit reposを使用する必要があるのは、ブランチをそこにプッシュできるため、誰かが作業しているものを管理できないためです。それでも裸ではないリポジトリにpushすることはできますが、誰かがその作業ディレクトリで作業しているブランチを移動できる可能性があるため、拒否されます。

そのため、作業フォルダのないプロジェクトでは、gitがオブジェクトを格納しているオブジェクトのみを表示できます。それらは圧縮されてシリアル化され、コンテンツのSHA1（ハッシュ）の下に保存されます。ベアリポジトリ内のオブジェクトを取得するには、表示するオブジェクトgit showのsha1を指定する必要があります。プロジェクトのような構造は表示されません。

ベアリポジトリは通常、誰もが作業を移す中心的なリポジトリです。実際の作業を操作する必要はありません。これは、複数の人の間で作業を同期させる方法です。プロジェクトファイルを直接表示することはできません。

プロジェクトで作業しているのがあなただけの場合、または「論理的に中央の」リポジトリが必要ない、または必要がない場合は、ベアリポジトリは必要ない場合があります。その場合、他のリポジトリgit pull からのほうが望ましいでしょう。これにより、gitが非ベアリポジトリにプッシュするときに発生する異論を回避できます。

お役に立てれば

短い答え

ベアリポジトリは作業コピーのないgitリポジトリであるため、.gitのコンテンツはそのディレクトリのトップレベルです。

ローカルで作業するには非ベアリポジトリを使用し、変更を他の人と共有するには中央サーバー/ハブとしてベアリポジトリを使用します。たとえば、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

その後、それをリモートとして追加することで、入力を保存できます。

サーバー側のリポジトリは、ファイルを編集してサーバーマシンでコミットするのではなく、プルとプッシュを介してコミットを取得するため、ベアリポジトリになります。

細部

ベアリポジトリではないリポジトリに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'.

この警告はスキップできます。ただし、推奨される設定は、ローカルで動作するように非ベアリポジトリを使用し、ハブまたは中央サーバーとしてベアリポジトリを使用してプッシュおよびプルすることです。

他の開発者の作業コピーと直接作業を共有したい場合は、プッシュする代わりに他のリポジトリからプルすることができます。

少し前にこの質問を読んだとき、すべてが私を混乱させました。私はgitを使い始めたばかりで、これらの作業用コピーがあります（現時点では何も意味していません）。用語について何も考えずにgitを始めたばかりの人の観点からこれを説明しようと思います。

違いの良い例は、次のように説明できます。

--bare保管場所を提供します（そこで開発することはできません）。--bareそれがなければ、そこで開発する（そして保管場所を持つ）ことができます。

git init現在のディレクトリからgitリポジトリを作成します。その中に.gitフォルダーを追加し、変更履歴を開始できるようにします。

git init --bareリポジトリも作成しますが、作業ディレクトリはありません。つまり、ファイルを編集したり、変更をコミットしたり、そのリポジトリに新しいファイルを追加したりすることはできません。

いつ--bare役立つか あなたと他の数人の人がプロジェクトに取り組んでいて、gitを使用しています。一部のサーバーでプロジェクトをホストしました（amazon ec2）。それぞれに独自のマシンがあり、コードをにプッシュしますec2。実際には何も開発していec2ません（マシンを使用しています）。コードをプッシュするだけです。だからあなたec2はあなたのすべてのコードのための単なるストレージで--bareあり、すべてのあなたのマシンと同じように作成する必要があります--bare（おそらく1つだけで、他のものはすべてのクローンを作成します）。ワークフローは次のようになります。

デフォルトのGitリポジトリは、作業ディレクトリとして使用することを想定しています。通常、サーバーを使用している場合は、作業ディレクトリを用意する必要はありません。ただのリポジトリ。この場合、--bareオプションを使用する必要があります。

非ベアリポジトリがデフォルトです。これは、を実行したときに作成されるgit initもの、またはbareサーバーから（オプションなしで）クローンを作成したときに取得されるものです。

このようなリポジトリを使用すると、リポジトリ内のすべてのファイルを表示および編集できます。変更をコミットするなどしてリポジトリを操作すると、Gitはと呼ばれる隠しディレクトリに変更を保存します.git。

gitサーバーがある場合は、ファイルの作業用コピーを用意する必要はありません。必要なのは、に保存されているGitデータだけ.gitです。ベアリポジトリはまさに.gitディレクトリであり、ファイルを変更およびコミットするための作業領域はありません。

サーバーからクローンを作成すると、Gitは.git作業コピーを作成するためにディレクトリに必要なすべての情報を持っています。

--bareリポジトリとワーキングツリーリポジトリのもう1つの違いは、最初のケースでは失われたコミットは保存されず、ブランチトラックに属するコミットのみが保存されることです。一方、Working Treeはすべてのコミットを永久に保持します。下記参照...

で最初のリポジトリ（名前：git-bare）を作成しましたgit init --bare。それはサーバーです。これは左側にあり、リモートリポジトリ自体であるため、リモートブランチはありません。

最初のものから2番目のリポジトリー（名前：git-working-tree）を作成git cloneしました。右にありますよ。リモートブランチにリンクされたローカルブランチがあります。

（テキスト「first」、「second」、「third」、「fourth」、「alpha」、「beta」、「delta」はコミットコメントです。「master」と「greek」はブランチ名です。）

ここで、git-bare（コマンド：）git push --delete origin greekとローカルのgit-working-tree（コマンド：）の両方で「greek」という名前のブランチを削除しgit branch -D greekます。ツリーの外観は次のとおりです。

git-裸のリポジトリはブランチとすべての参照comitsの両方を削除します。写真では、この理由でツリーが縮小されていることがわかります。

一方、一般的に使用されるローカルリポジトリと同等のgit-working-treeリポジトリは、git checkout 7fa897b7コマンドを使用してハッシュから直接参照できるようになったコミットを削除しません。そのため、ツリーの構造は変更されていません。

概要：コミットは作業ツリーリポジトリでは削除されませんが、ベアリポジトリでは削除されます。

実際には、サーバー上で削除されたブランチがローカルリポジトリに存在する場合にのみ、回復できます。

しかし、リモートブランチを削除した後、ベアリポジトリのサイズがディスクサイズで減少しないのは非常に奇妙です。つまり、ファイルはまだ何らかの形で残っています。参照されなくなったものや参照できないもの（後者の場合）を削除してリポジトリをダンプするには、git gc --prune次のコマンドを使用します。