git-non-bare-repository

When creating a git repository that will be on the server, can I convert it to a bare repository? [duplicate]

人走茶凉 — Tue, 17 Dec 2019 14:27:17 +0000

When creating a git repository that will be on the server, can I convert it to a bare repository? [duplicate] 人走茶凉 2019-12-17 22:27:17

问题

I already created a repository. Can I make it a bare type or shall I start over?

回答1:

According to the FAQ, conversion from non-bare to bare can be done in two ways. The best one:

$ git clone --bare -l repo repo.git
$ rm -rf repo

To create a bare repository from scratch:

$ mkdir repo.git
$ cd repo.git
$ git --bare init

回答2:

Just move the .git folder away from the working copy.

mv /var/git/repo/repo/.git /var/git/repos/repo.git

You might want to follow that up with a

git config --bool core.bare true

in that repository, just in case git complains about something not being right.

回答3:

git clone --bare repo

This will give you a new bare version of repo named repo.git. Easy, no?

来源：https://stackoverflow.com/questions/1784506/when-creating-a-git-repository-that-will-be-on-the-server-can-i-convert-it-to-a

标签

git-bare

What are the consequences of using receive.denyCurrentBranch in Git?

三世轮回 — Tue, 17 Dec 2019 00:23:29 +0000

What are the consequences of using receive.denyCurrentBranch in Git? 三世轮回 2019-12-17 08:23:29

问题

I have a Git repository. I have cloned the repository and can commit my local changes. When I push my changes to the server it works.

As soon as I create a branch, I checkout the branch, commit my work and then checkout the master branch. I then merge my local changes into the master branch. When I try to push to the server I get the following exception:

Welcome to Git (version 1.7.11-preview20120620)

Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

$ git push origin master:master
 Counting objects: 9, done.
 Delta compression using up to 4 threads.
 Compressing objects: 100% (7/7), done.
 Writing objects: 100% (8/8), 13.68 KiB, done.
 Total 8 (delta 2), reused 1 (delta 0)
 Unpacking objects: 100% (8/8), done.
 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'.
 To c:/jGit
 ! [remote rejected] master -> master (branch is currently checked out)
 error: failed to push some refs to 'c:/gitRepository'

One solution is to run the following command:

git config receive.denyCurrentBranch ignore

After this it works, but I would like to know why I need to use this option. Is this the only option? What are the consequences of doing this?

What I would really like to do is create branches, merge them into the master branch and then push my changes to the server.

回答1:

The server where you are pushing to should use bare repository.

How to convert a normal Git repository to a bare one?

回答2:

Why Git won't let you push to non-bare repositories

The original poster says:

One solution is to run the following command:
git config receive.denyCurrentBranch ignore
After this it works, but I would like to know why I need to use this option. Is this the only option? What are the consequences of doing this?

As I point out in my answer to a similar question, since Git version 1.6.2, Git won't let you push to a non-bare repository by default. This is because the git push command only updates the branch and HEAD references on the remote repository. What it doesn't do is also update the working-copy and staging-area in that non-bare remote.

As a consequence, when you use git status in the remote repo, you'll see that the repo's previous state is still present in the working copy (and staged in the index):

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   previous-state.txt

If you look at the error message that you got when you first tried to push to your non-bare remote repo with the receive.denyCurrentBranch setting set to the default refuse value, you'll see that the message tells you basically the same thing:

error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.

You should really just push to bare Git repositories

As pointed out in some of the other answers, you shouldn't really be pushing to a non-bare repository, for the reasons I pointed out above, and which Git itself is telling you.

So like what this answer states, a simple way to convert an existing non-bare repo to a bare one is to simply reclone it as a bare repo:

git clone --bare old-repo

Or you could try messing around with the core.bare config setting, as detailed in this answer.

回答3:

I had the same error and needed the repository to be running as a dev test page online (that is, I guess, to keep a non-bare repo). Hopefully I solved it by initiating the repository with this series of commands (since git 2.3):

git init
git config --global user.email "your@mail.here"
git config --global user.name "Your Name"
git commit
git config receive.denyCurrentBranch updateInstead

As seen here: cannot push into git repository

回答4:

You should have a bare repository on the server, not one with a checked-out working tree. Git is telling you it refuses to overwrite the branch that is currently checked out on the server.

See this answer for information on how to convert your non-bare repository on the server to a bare one.

回答5:

Autopsy of the Problem

When a branch is checked out, committing will add a new commit with the current branch's head as its parent and move the branch's head to be that new commit.

A ← B
    ↑
[HEAD,branch1]

becomes

A ← B ← C
        ↑
    [HEAD,branch1]

But if someone could push to that branch inbetween, the user would get itself in what git calls detached head mode:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Now the user is not in branch1 anymore, without having explicitly asked to check out another branch. Worse, the user is now outside any branch, and any new commit will just be dangling:

     [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Hypothetically, if at this point, the user checks out another branch, then this dangling commit becomes fair game for Git's garbage collector.

回答6:

I think a non bare repository can be useful when man configures the git update hook to deploy from the repository itself after the push happened. Just do not forget to reset the repository. If you miss that step files wont track the actual state...

来源：https://stackoverflow.com/questions/12265729/what-are-the-consequences-of-using-receive-denycurrentbranch-in-git

标签

git-config

When creating a git repository that will be on the server, can I convert it to a bare repository? [duplicate]

百般思念 — Thu, 28 Nov 2019 11:12:04 +0000

When creating a git repository that will be on the server, can I convert it to a bare repository? [duplicate] 百般思念 2019-11-28 19:12:04

This question already has an answer here:

How to convert a normal Git repository to a bare one? 16 answers

I already created a repository. Can I make it a bare type or shall I start over?

Jørn Schou-Rode

According to the FAQ, conversion from non-bare to bare can be done in two ways. The best one:

$ git clone --bare -l repo repo.git
$ rm -rf repo

To create a bare repository from scratch:

$ mkdir repo.git
$ cd repo.git
$ git --bare init

Bombe

Just move the .git folder away from the working copy.

mv /var/git/repo/repo/.git /var/git/repos/repo.git

You might want to follow that up with a

git config --bool core.bare true

in that repository, just in case git complains about something not being right.

git clone --bare repo

This will give you a new bare version of repo named repo.git. Easy, no?

来源：https://stackoverflow.com/questions/1784506/when-creating-a-git-repository-that-will-be-on-the-server-can-i-convert-it-to-a

标签

git-bare

How to convert a normal Git repository to a bare one?

What are the consequences of using receive.denyCurrentBranch in Git?

[亡魂溺海] — Tue, 26 Nov 2019 22:40:22 +0000

What are the consequences of using receive.denyCurrentBranch in Git? [亡魂溺海] 2019-11-27 06:40:22

I have a Git repository. I have cloned the repository and can commit my local changes. When I push my changes to the server it works.

Welcome to Git (version 1.7.11-preview20120620)

Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

$ git push origin master:master
 Counting objects: 9, done.
 Delta compression using up to 4 threads.
 Compressing objects: 100% (7/7), done.
 Writing objects: 100% (8/8), 13.68 KiB, done.
 Total 8 (delta 2), reused 1 (delta 0)
 Unpacking objects: 100% (8/8), done.
 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'.
 To c:/jGit
 ! [remote rejected] master -> master (branch is currently checked out)
 error: failed to push some refs to 'c:/gitRepository'

One solution is to run the following command:

git config receive.denyCurrentBranch ignore

After this it works, but I would like to know why I need to use this option. Is this the only option? What are the consequences of doing this?

What I would really like to do is create branches, merge them into the master branch and then push my changes to the server.

kan

The server where you are pushing to should use bare repository.

Why Git won't let you push to non-bare repositories

The original poster says:

One solution is to run the following command:
git config receive.denyCurrentBranch ignore
After this it works, but I would like to know why I need to use this option. Is this the only option? What are the consequences of doing this?

As a consequence, when you use git status in the remote repo, you'll see that the repo's previous state is still present in the working copy (and staged in the index):

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   previous-state.txt

error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.

You should really just push to bare Git repositories

As pointed out in some of the other answers, you shouldn't really be pushing to a non-bare repository, for the reasons I pointed out above, and which Git itself is telling you.

So like what this answer states, a simple way to convert an existing non-bare repo to a bare one is to simply reclone it as a bare repo:

git clone --bare old-repo

Or you could try messing around with the core.bare config setting, as detailed in this answer.

Fanky

git init
git config --global user.email "your@mail.here"
git config --global user.name "Your Name"
git commit
git config receive.denyCurrentBranch updateInstead

As seen here: cannot push into git repository

Carl-Eric Menzel

You should have a bare repository on the server, not one with a checked-out working tree. Git is telling you it refuses to overwrite the branch that is currently checked out on the server.

See this answer for information on how to convert your non-bare repository on the server to a bare one.

Autopsy of the Problem

When a branch is checked out, committing will add a new commit with the current branch's head as its parent and move the branch's head to be that new commit.

A ← B
    ↑
[HEAD,branch1]

becomes

A ← B ← C
        ↑
    [HEAD,branch1]

But if someone could push to that branch inbetween, the user would get itself in what git calls detached head mode:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Now the user is not in branch1 anymore, without having explicitly asked to check out another branch. Worse, the user is now outside any branch, and any new commit will just be dangling:

     [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Hypothetically, if at this point, the user checks out another branch, then this dangling commit becomes fair game for Git's garbage collector.

来源：https://stackoverflow.com/questions/12265729/what-are-the-consequences-of-using-receive-denycurrentbranch-in-git

标签

git-config

How to push to a non-bare Git repository?

最后都变了- — Mon, 25 Nov 2019 16:39:54 +0000

How to push to a non-bare Git repository? 最后都变了- 2019-11-26 00:39:54

问题

I usually work on a remote server via ssh (screen and vim), where I have a Git repository. Sometimes I\'m not online, so I have a separate repository (cloned from my remote) on my laptop.

However, I can\'t pull from this repository on remote side because I\'m usually behind a firewall or I don\'t have a public IP.

I\'ve read that I should push just to a bare repository. How should I then push my changes to my remote repository?

回答1:

receive.denyCurrentBranch updateInstead

This options was added in Git 2.3, and it makes the server update its working tree if it is clean.

So if you ensure that you always commit before you pull locally, and keep a clean working tree on the server (which you should do to avoid having merge conflicts), then this option is a good solution.

Sample usage:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Output:

a
b

回答2:

Best Option

Probably the cleanest, least confusing, and safest way to push into your non-bare remote repository, is to push to dedicated branches in the remote that represent your laptop branches.

Let's look at the simplest case, and assume you have just one branch in each repo: master. When you push to the remote repo from your laptop, instead of pushing master -> master, push master -> laptop-master (or a similar name). This way the push doesn't affect the currently checked-out master branch in the remote repo. To do this from the laptop, the command is pretty simple:

git push origin master:laptop-master

This means that the local master branch will be pushed to the branch named "laptop-master" in the remote repository. In your remote repo, you'll have a new branch named "laptop-master" that you can then merge into your remote master when you are ready.

Alternate Option

It's also possible to just push master -> master, but pushing to the currently checked-out branch of a non-bare repo is generally not recommended, because it can be confusing if you don't understand what is going on. This is because pushing to a checked-out branch doesn't update the work tree, so checking git status in the checked-out branch that was pushed into will show exactly the opposite differences as what was most recently pushed. It would get especially confusing if the work tree was dirty before the push was done, which is a big reason why this is not recommended.

If you want to try just pushing master -> master, then the command is just:

git push origin

But when you go back to the remote repo, you'll most likely want to do a git reset --hard HEAD to get the work tree in sync with the content that was pushed. This can be dangerous, because if there are any uncommitted changes in the remote work tree that you wanted to keep it will wipe them out. Be sure you know what the consequences of this are before you try it, or at least make a backup first!

EDIT Since Git 2.3, you can use "push-to-deploy" git push: https://github.com/blog/1957-git-2-3-has-been-released. But pushing to a separate branch and then merging is usually better since it does an actual merge (hence works with uncommitted changes just like merge does).

回答3:

I would suggest to have a bare-repository and a local working (non-bare) repos in your server. You could push changes from laptop to server bare repo and then pull from that bare repo to server working repo. The reason I say this is because you might have many complete/incomplete branches in server which you will want to replicate on the laptop.

This way you don't have to worry about the state of the branch checked out on server working repo while pushing changes to server.

回答4:

Another option is to setup a reverse ssh tunnel so that you can pull instead of push.

# start the tunnel from the natted box you wish to pull from (local)
$ ssh -R 1234:localhost:22 user@remote

# on the other box (remote)
$ git remote add other-side ssh://user@localhost:1234/the/repo
$ git pull other-side

And if you want the tunnel to run in the background

$ ssh -fNnR 1234:localhost:22 user@remote

回答5:

You can do:

$git config --bool core.bare true

this can be done in bare or central repository so that it will accept any files that are pushed from non bare repositories. If you do this in non bare repository then we cannot push any files from non bare to bare repository.

If you are practicing GIT by creating central and non bare repo in PC it might not show the pushed files in some PC's but it has been pushed. you can check it by running.

$git log in central repo.

Other than if you push to GitHub it will show the files there.

来源：https://stackoverflow.com/questions/1764380/how-to-push-to-a-non-bare-git-repository

标签

How do I properly force a Git push?

╄→尐↘猪︶ㄣ — Mon, 25 Nov 2019 16:26:24 +0000

How do I properly force a Git push? ╄→尐↘猪︶ㄣ 2019-11-26 00:26:24

问题

I\'ve set up a remote non-bare \"main\" repo and cloned it to my computer. I made some local changes, updated my local repository, and pushed the changes back to my remote repo. Things were fine up to that point.

Now, I had to change something in the remote repo. Then I changed something in my local repo. I realized that the change to the remote repo was not needed. So I tried to git push from my local repo to my remote repo, but I got an error like:

To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the \'Note about fast-forwards\' section of git push --help for details.

I thought that probably a

git push --force

would force my local copy to push changes to the remote one and make it the same. It does force the update, but when I go back to the remote repo and make a commit, I notice that the files contain outdated changes (ones that the main remote repo previously had).

As I mentioned in the comments to one of the answers:

[I] tried forcing, but when going back to master server to save the changes, i get outdated staging. Thus, when i commit the repositories are not the same. And when i try to use git push again, i get the same error.

How can I fix this issue?

回答1:

Just do:

git push origin <your_branch_name> --force

or if you have a specific repo:

git push https://git.... --force

This will delete your previous commit(s) and push your current one.

It may not be proper, but if anyone stumbles upon this page, thought they might want a simple solution...

Short flag

Also note that -f is short for --force, so

git push origin <your_branch_name> -f

will also work.

回答2:

And if push --force doesn't work you can do push --delete. Look at 2^nd line on this instance:

git reset --hard HEAD~3  # reset current branch to 3 commits ago
git push origin master --delete  # do a very very bad bad thing
git push origin master  # regular push

But beware...

Never ever go back on a public git history!

In other words:

Don't ever force push on a public repository.
Don't do this or anything that can break someone's pull.
Don't ever reset or rewrite history in a repo someone might have already pulled.

Of course there are exceptionally rare exceptions even to this rule, but in most cases it's not needed to do it and it will generate problems to everyone else.

Do a revert instead.

And always be careful with what you push to a public repo. Reverting:

git revert -n HEAD~3..HEAD  # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master  # regular push

In effect, both origin HEADs (from the revert and from the evil reset) will contain the same files.

edit to add updated info and more arguments around `push --force`

Consider pushing force with lease instead of push, but still prefer revert

Another problem push --force may bring is when someone push anything before you do, but after you've already fetched. If you push force your rebased version now you will replace work from others.

git push --force-with-lease introduced in the git 1.8.5 (thanks to @VonC comment on the question) tries to address this specific issue. Basically, it will bring an error and not push if the remote was modified since your latest fetch.

This is good if you're really sure a push --force is needed, but still want to prevent more problems. I'd go as far to say it should be the default push --force behaviour. But it's still far from being an excuse to force a push. People who fetched before your rebase will still have lots of troubles, which could be easily avoided if you had reverted instead.

And since we're talking about git --push instances...

Why would anyone want to force push?

@linquize brought a good push force example on the comments: sensitive data. You've wrongly leaked data that shouldn't be pushed. If you're fast enough, you can "fix"* it by forcing a push on top.

* The data will still be on the remote unless you also do a garbage collect, or clean it somehow. There is also the obvious potential for it to be spread by others who'd fetched it already, but you get the idea.

回答3:

First of all, I would not make any changes directly in the "main" repo. If you really want to have a "main" repo, then you should only push to it, never change it directly.

Regarding the error you are getting, have you tried git pull from your local repo, and then git push to the main repo? What you are currently doing (if I understood it well) is forcing the push and then losing your changes in the "main" repo. You should merge the changes locally first.

回答4:

If I'm on my local branch A, and I want to force push local branch B to the origin branch C I can use the following syntax:

git push --force origin B:C

回答5:

I would really recommend to:

push only to the main repo
make sure that main repo is a bare repo, in order to never have any problem with the main repo working tree being not in sync with its .git base. See "How to push a local git repository to another computer?"
If you do have to make modification in the main (bare) repo, clone it (on the main server), do your modification and push back to it

In other words, keep a bare repo accessible both from the main server and the local computer, in order to have a single upstream repo from/to which to pull/pull.

回答6:

use this following command:

git push -f origin master

回答7:

This was our solution for replacing master on a corporate gitHub repository while maintaining history.

push -f to master on corporate repositories is often disabled to maintain branch history. This solution worked for us.

git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master

git checkout currentBranch  // move to target branch
git merge -s ours master  // merge using ours over master
// vim will open for the commit message
git checkout master  // move to master
git merge currentBranch  // merge resolved changes into master

push your branch to desiredOrigin and create a PR

回答8:

I had the same question but figured it out finally. What you most likely need to do is run the following two git commands (replacing hash with the git commit revision number):

git checkout <hash>
git push -f HEAD:master

来源：https://stackoverflow.com/questions/5509543/how-do-i-properly-force-a-git-push

标签

push

How to convert a normal Git repository to a bare one?

拟墨画扇 — Mon, 25 Nov 2019 15:19:40 +0000

How to convert a normal Git repository to a bare one? 拟墨画扇 2019-11-25 23:19:40

问题

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

回答1:

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

回答2:

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.

回答3:

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

回答4:

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

回答5:

Please also consider to use

git clone --mirror path_to_source_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.

回答6:

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.

回答7:

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

回答8:

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

回答9:

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

回答10:

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.

回答11:

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.

回答12:

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.

create a bare repository
cd into the local repository which has local checkedout branches and remote branches
git push /path/to/bare/repo +refs/remotes/origin/:refs/heads/

回答13:

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

回答14:

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

回答15:

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)

回答16:

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.

来源：https://stackoverflow.com/questions/2199897/how-to-convert-a-normal-git-repository-to-a-bare-one

标签