629

How can I convert a 'normal' Git repository to a bare one?

The main difference seems to be:

  • in the normal Git repository, you have a .git folder inside the repository containing all relevant data and all other files making up your working copy

  • in a bare Git repository, there is no working copy and the folder (let's call it repo.git) contains the actual repository data

Matthias Braun
  • 24,493
  • 16
  • 114
  • 144
Boldewyn
  • 75,918
  • 43
  • 139
  • 205

17 Answers17

653

In short: replace the contents of repo with the contents of repo/.git, then tell the repository that it is now a bare repository.

To do this, execute the following commands:

cd repo
mv .git ../repo.git # renaming just for clarity
cd ..
rm -fr repo
cd repo.git
git config --bool core.bare true

Note that this is different from doing a git clone --bare to a new location (see below).

Schwertspize
  • 151
  • 9
Jörg W Mittag
  • 337,159
  • 71
  • 413
  • 614
  • 10
    Thanks for the hint at `core.bare`. Now, after googling this option, I can confirm it: http://www.kernel.org/pub/software/scm/git-core/docs/git-config.html – Boldewyn Feb 05 '10 at 11:01
  • Can I go ahead and delete any branch/remote information left in the config file? I'd previously clones from another and am switching my local copy to be a remote 'master'... thanks – Toby May 28 '12 at 14:42
  • 15
    Thank you! This seems cleaner to me: mv repo/.git repo.git && rm -rf repo && cd repo.git && git config --bool core.bare true – JasonWoof Jun 21 '12 at 09:43
  • will the files still exist if I did this? – Jürgen Paul Jun 26 '12 at 08:51
  • 62
    This is so much more complicated and fragile than the answer below (`git clone --bare /path/to/repo`). – djd Jul 06 '12 at 00:16
  • 7
    That `rm` command may need `* \.[!.]*` rather than `*` in order to remove dot-files and dot-directories. – minopret Aug 27 '12 at 18:25
  • This command assumes that directory `../` doesn't have `.git` directory or file inside. If so, it may cause unexpected behavior. – Ciantic Jan 07 '13 at 20:03
  • 8
    @Ciantic: Again, as I already explained in my comment above, my answer was given 3 years ago, but 5 months ago someone edited the question into something *completely* different. *None* of the answers on this page will make *any* sense anymore. That sequence of commands was directly copied from the question, I just added the last two lines. – Jörg W Mittag Jan 07 '13 at 22:02
  • 3
    .git/index can be removed too, bare repo does not need it. – user1338062 Feb 22 '13 at 10:07
  • 6
    The link that @Boldewyn points to confirming the core.bare section has moved to: https://www.kernel.org/pub/software/scm/git/docs/git-config.html – Alan W. Smith Mar 08 '13 at 07:21
  • 2
    I find that this answer: http://stackoverflow.com/a/1784612/2498188 is much cleaner. – Emily L. Sep 16 '13 at 11:15
  • 3
    I tried both this and the following clone option, and the result differs. Also the wiki recommends to use the clone approach, see https://git.wiki.kernel.org/index.php/Git_FAQ#How_do_I_make_existing_non-bare_repository_bare.3F – ggll Nov 29 '13 at 13:34
  • If you have **SourceTree** installed you simply can checkout the bare repository to a new folder by... _Selecting "New Repository -> Clone from URL", Copy&Paste the path to the local folder into "Source URL", Clicking "Clone"_. This will create a new folder with the checked out bare repository. – Bouncing Bit Feb 02 '15 at 09:19
  • Didn't work for me. I had conflicts to resolve which does not make sense. – ceztko Apr 21 '15 at 22:10
  • `cd repo ; cp -r .git ../repo.git` – manish_s Jul 11 '15 at 16:01
  • 1
    I must tell that gitlab thinks the repo is empty after this operation – gyorgyabraham Jan 31 '17 at 15:31
  • 2
    This answer does not work as written if the repository you want to convert happens to be a module of an existing repository. In this case `.git` is not a directory but a file that contains the path to the actual `.git` directory you must move. – Psychonaut Sep 03 '18 at 07:51
  • Do we have to do [this](https://stackoverflow.com/questions/2199897/how-to-convert-a-normal-git-repository-to-a-bare-one#comment82188196_2199939) afterward? – Keith Russell Jan 27 '21 at 19:55
  • I think log folder need to be deleted too. Also to those 61 people who think `git clone` is a better solution, try doing it 397 times (re-constructing a vanished server) – AaA Jan 30 '21 at 12:05
253

Your method looks like it would work; the file structure of a bare repository is just what is inside the .git directory. But I don't know if any of the files are actually changed, so if that fails, you can just do

git clone --bare /path/to/repo

You'll probably need to do it in a different directory to avoid a name conflict, and then you can just move it back to where you want. And you may need to change the config file to point to wherever your origin repo is.

jonescb
  • 19,527
  • 6
  • 44
  • 41
  • 54
    Wrong, this method is not the equivalent. Doing a clone doesn't preserve config options, which can be critical to proper operation such as if you use git-p4. Additionally, a clone destroys remotes, again with something like git-p4 you lose the p4/master branch when you clone, so the above approach is preferable. – nosatalian Apr 21 '10 at 02:00
  • 27
    But you can transfer config options easily by copying the respective parts of the config file. I'd still consider this method to be cleaner than copying and renaming files manually. – Philipp Jun 29 '10 at 09:50
  • 6
    This is perfect after a subversion migration since git-svn lacks support for --bare. – Keyo Jan 07 '11 at 07:23
  • 11
    To avoid the name conflict --- `git clone --bare /path/to/repo.git /path/to/newbarerepo.git` – raksja Jul 27 '12 at 05:20
  • This works as long as you run `git update-server-info` on the bare repo after creation. – ACK_stoverflow Dec 03 '17 at 03:13
120

I think the following link would be helpful

GitFaq: How do I make existing non-bare repository bare?

$ mv repo/.git repo.git
$ git --git-dir=repo.git config core.bare true
$ rm -rf repo
Antony Hatchkins
  • 25,545
  • 8
  • 96
  • 98
xhh
  • 3,872
  • 2
  • 19
  • 17
  • 2
    Yes, that's quite what I searched, thanks! However, their second proposal (`git clone`) has the drawbacks that nosatalian mentioned above. – Boldewyn Aug 03 '10 at 06:42
  • 1
    The documentation you suggested goes on to say, "A safer method is to let Git handle all the internal settings for you by doing something like this... git clone --bare -l " – dafunker Sep 29 '16 at 09:31
76

Unless you specifically want or need to twiddle bits on the filesystem, it really is dead simple to create a bare version of a non-bare repository (mentioned in several other posts here). It’s part of git’s core functionality:

git clone --bare existing_repo_path bare_repo_path

Jacek Krawczyk
  • 1,505
  • 1
  • 13
  • 22
Chip Kaye
  • 1,357
  • 11
  • 13
  • 6
    Kind of amazing that the far-and-away best answer has 0 votes after > 4 months. The not-very-good-but-dangerous 'accepted answer' has 200! – Stabledog Jul 24 '13 at 23:02
  • 40
    Not amazing at all - this answer does not do what the original question asked. It doesn't convert a repo, it clones one, losing information in the process (for example, remote branches). – GreenAsJade Nov 11 '13 at 03:21
  • Of course it begs the question why Git is lossy in the first place (and yeah, I know of `git clone --mirror`) but to the best of my knowledge the meaning of _clone_ in English isn't "duplicate except for these random unspecified parts" ... of course the meaning of Git subcommands isn't always exactly self-explanatory, so I guess I'm doing Git wrong by expecting English subcommands to follow the English meaning of the words. – 0xC0000022L Apr 12 '21 at 11:48
19

Please also consider to use

git clone --mirror path_to_source_repository path_to_bare_repository

From the documentation:

Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.

Jacek Krawczyk
  • 1,505
  • 1
  • 13
  • 22
  • Seems like this is the most concise, complete and safe way to do what the OP wants (vs. just `clone`). Am I missing something? Was `--mirror` a relatively recent addition? – Craig Silver Dec 26 '17 at 17:31
  • @CraigSilver: No, as I see in the documentation history in such a form the `--mirror` is available from the version 1.7, so already pretty long. You can check out [here](https://git-scm.com/docs/git-clone/1.7.12.4) – Jacek Krawczyk Dec 27 '17 at 07:46
8

I just wanted to push to a repository on a network path but git would not let me do that unless that repository was marked as bare. All I needed was to change its config:

git config --bool core.bare true

No need to fiddle with the files unless you want to keep it clean.

Slion
  • 1,407
  • 16
  • 19
  • 3
    This is dangerous, when you also want to work on the work tree of the remote repo. Chances are, that sooner or later you revert a change simply because your remote work tree and index weren't in sync with the repository. I do not recommend this solution, if you do not _exactly_ know what you're doing. – Boldewyn Feb 24 '16 at 07:23
  • True, you should not work on the tree of the remote bare repo. – Slion Mar 04 '16 at 10:21
6

i've read the answers and i have done this:

cd repos
mv .git repos.git
cd repos.git
git config --bool core.bare true # from another answer
cd ../
mv repos.git ../
cd ../
rm -rf repos/ # or delete using a file manager if you like

this will leave the contents of repos/.git as the bare repos.git

Dan D.
  • 67,516
  • 13
  • 93
  • 109
4

Simply read

Pro Git Book: 4.2 Git on the Server - Getting Git on a Server

which boild down to

$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.

Then put my_project.git to the server

Which mainly is, what answer #42 tried to point out. Shurely one could reinvent the wheel ;-)

Community
  • 1
  • 1
apos
  • 161
  • 3
  • I fail to see, what this answer adds, that hasn’t been discussed in arbitrary length in _any_ of the other answers around (including the downvoted). Could you please clarify? (By the way: the Pro Git Book says _“This is roughly equivalent to something like…”_, and that exact rough equivalence is also already discussed here.) – Boldewyn Nov 04 '15 at 19:29
4

Here's what I think is safest and simplest. There is nothing here not stated above. I just want to see an answer that shows a safe step-by-step procedure. You start one folder up from the repository (repo) you want to make bare. I've adopted the convention implied above that bare repository folders have a .git extension.

(1) Backup, just in case.
    (a) > mkdir backup
    (b) > cd backup
    (c) > git clone ../repo
(2) Make it bare, then move it
    (a) > cd ../repo
    (b) > git config --bool core.bare true
    (c) > mv .git ../repo.git
(3) Confirm the bare repository works (optional, since we have a backup)
    (a) > cd ..
    (b) > mkdir test
    (c) > cd test
    (d) > git clone ../repo.git
(4) Clean up
    (a) > rm -Rf repo
    (b) (optional) > rm -Rf backup/repo
    (c) (optional) > rm -Rf test/repo
  • 1
    this isn't really much safer since you made your backup using git clone. Backup by cloning will cause you to lose some configurations, which in certain cases might be critical for the repository. – Lie Ryan Jul 25 '12 at 09:24
  • Noted. The only configurations I've ever cared about are global to all my local repositories. – sdesciencelover Aug 13 '12 at 12:57
3

Here is a little BASH function you can add to your .bashrc or .profile on a UNIX based system. Once added and the shell is either restarted or the file is reloaded via a call to source ~/.profile or source ~/.bashrc.

function gitToBare() {
  if [ -d ".git" ]; then
    DIR="`pwd`"
    mv .git ..
    rm -fr *
    mv ../.git .
    mv .git/* .
    rmdir .git

    git config --bool core.bare true
    cd ..
    mv "${DIR}" "${DIR}.git"

    printf "[\x1b[32mSUCCESS\x1b[0m] Git repository converted to "
    printf "bare and renamed to\n  ${DIR}.git\n"
    cd "${DIR}.git"
  else
    printf "[\x1b[31mFAILURE\x1b[0m] Cannot find a .git directory\n"
  fi
}

Once called within a directory containing a .git directory, it will make the appropriate changes to convert the repository. If there is no .git directory present when called, a FAILURE message will appear and no file system changes will happen.

nyteshade
  • 1,973
  • 1
  • 11
  • 8
1

The methods that say to remove files and muck about with moving the .git directory are not clean and not using the "git" method of doing something that's should be simple. This is the cleanest method I have found to convert a normal repo into a bare repo.

First clone /path/to/normal/repo into a bare repo called repo.git

git clone --bare /path/to/normal/repo

Next remove the origin that points to /path/to/normal/repo

cd repo.git
git remote rm origin

Finally you can remove your original repo. You could rename repo.git to repo at that point, but the standard convention to signify a git repository is something.git, so I'd personally leave it that way.

Once you've done all that, you can clone your new bare repo (which in effect creates a normal repo, and is also how you would convert it from bare to normal)

Of course if you have other upstreams, you'll want to make a note of them, and update your bare repo to include it. But again, it can all be done with the git command. Remember the man pages are your friend.

krux
  • 29
  • 2
  • 1
    Have you bothered to read the other answers? Especially @jonescb's and @nosatalian's comment to it? The "git" method is this: "Do as much as possible with plain text files". You should start investigating the internals of a `.git` folder. It's highly educating to learn, how the parts fit together. – Boldewyn Jun 04 '14 at 20:49
1

In case you have a repository with few local checkedout branches /refs/heads/* and few remote branch branches remotes/origin/* AND if you want to convert this into a BARE repository with all branches in /refs/heads/*

you can do the following to save the history.

  1. create a bare repository
  2. cd into the local repository which has local checkedout branches and remote branches
  3. git push /path/to/bare/repo +refs/remotes/origin/:refs/heads/
Senthil A Kumar
  • 8,034
  • 13
  • 41
  • 53
1

Here is the definition of a bare repository from gitglossary:

A bare repository is normally an appropriately named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the Git administrative and control files that would normally be present in the hidden .git sub-directory are directly present in the repository.git directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.

I arrived here because I was playing around with a "local repository" and wanted to be able to do whatever I wanted as if it were a remote repository. I was just playing around, trying to learn about git. I'll assume that this is the situation for whoever wants to read this answer.

I would love for an expert opinion or some specific counter-examples, however it seems that (after rummaging through some git source code that I found) simply going to the file .git/config and setting the core attribute bare to true, git will let you do whatever you want to do to the repository remotely. I.e. the following lines should exist in .git/config:

[core]
    ...
    bare = true
...

(This is roughly what the command git config --bool core.bare true will do, which is probably recommended to deal with more complicated situations)

My justification for this claim is that, in the git source code, there seems to be two different ways of testing if a repo is bare or not. One is by checking a global variable is_bare_repository_cfg. This is set during some setup phase of execution, and reflects the value found in the .git/config file. The other is a function is_bare_repository(). Here is the definition of this function:

int is_bare_repository(void)
{
    /* if core.bare is not 'false', let's see if there is a work tree */
    return is_bare_repository_cfg && !get_git_work_tree();
} 

I've not the time nor expertise to say this with absolute confidence, but as far as I could tell if you have the bare attribute set to true in .git/config, this should always return 1. The rest of the function probably is for the following situation:

  1. core.bare is undefined (i.e. neither true nor false)
  2. There is no worktree (i.e. the .git subdirectory is the main directory)

I'll experiment with it when I can later, but this would seem to indicate that setting core.bare = true is equivalent to removeing core.bare from the config file and setting up the directories properly.

At any rate, setting core.bare = true certainly will let you push to it, but I'm not sure if the presence of project files will cause some other operations to go awry. It's interesting and I suppose instructive to push to the repository and see what happened locally (i.e. run git status and make sense of the results).

Nathan Chappell
  • 1,286
  • 11
  • 17
0

I used the following script to read a text file that has a list of all my SVN repos and convert them to GIT, and later use git clone --bare to convert to a bare git repo

#!/bin/bash
file="list.txt"
while IFS= read -r repo_name
do
 printf '%s\n' "$repo_name"
 sudo git svn clone --shared --preserve-empty-dirs --authors-file=users.txt file:///programs/svn/$repo_name 
 sudo git clone --bare /programs/git/$repo_name $repo_name.git
 sudo chown -R www-data:www-data $repo_name.git
 sudo rm -rf $repo_name
done <"$file"

list.txt has the format

repo1_name
repo2_name

and users.txt has the format

(no author) = Prince Rogers <prince.rogers.nelson@payesley.park.org>

www-data is the Apache web server user, permission is needed to push changes over HTTP

Pedro Vicente
  • 443
  • 1
  • 5
  • 17
-1

First, backup your existing repo:

(a)  mkdir backup

(b)  cd backup

(c)  git clone non_bare_repo

Second, run the following:

git clone --bare -l non_bare_repo new_bare_repo
gks
  • 3,368
  • 3
  • 27
  • 44
Shaks
  • 7
  • 1
-4

Oneliner for doing all of the above operations:

for i in `ls -A .`; do if [ $i != ".git" ]; then rm -rf $i; fi; done; mv .git/* .; rm -rf .git; git config --bool core.bare true

(don't blame me if something blows up and you didn't have backups :P)

Tarmo
  • 5,864
  • 2
  • 17
  • 12
-9

Wow, it's simply amazing how many people chimed in on this, especially considering it doesn't seem that not a single on stopped to ask why this person is doing what he's doing.

The ONLY difference between a bare and non-bare git repository is that the non-bare version has a working copy. The main reason you would need a bare repo is if you wanted to make it available to a third party, you can't actually work on it directly so at some point you're going to have to clone it at which point you're right back to a regular working copy version.

That being said, to convert to a bare repo all you have to do is make sure you have no commits pending and then just :

rm -R * && mv .git/* . && rm -R .git

There ya go, bare repo.

Justin Buser
  • 2,757
  • 22
  • 31
  • 11
    This will not make it bare enough. Try pushing into it. You need to do `git config core.bare true` as well. – Antony Hatchkins Aug 01 '12 at 11:39
  • I didn't downvote, but I just wanted to point out that the 1st part of this answer that explains *why* you would want a bare repo vs a non-bare one is *ok*, though it doesn't contain enough technical detail, and may be slightly inaccurate. **However**, for the 2nd part of your answer, while those commands do set up your repo to be bare, [Anthony is right](http://stackoverflow.com/questions/2199897/how-to-convert-a-git-repository-from-normal-to-bare#comment15610551_9964602), you still need to set `git config core.bare true`, just like in [this answer](http://stackoverflow.com/a/2200662/456814). –  Jul 30 '14 at 18:40