1

Context:

  • User "dev", home directory /home/dev
  • Production code in what I'll call /thepath/codebase
  • Working directory /thepath/dev (currently with files that should be a branch)
  • Project is called KizunaDB

Ultimately I want a bare repo called kizunadb.git somewhere (I guess my home directory is logical) that I want seen as the "original", where everything clones from. (per conclusions from this discussion)

Not knowing how to start with an empty bare repo and then put files into it from elsewhere, I tried starting where the files are. I successfully made a repo in /thepath/codebase and committed all the files. Then I did:

cd ~
mkdir kizunadb.git
cd kizunadb.git
git clone --bare /thepath/codebase

Hmm... that made /home/dev/kizunadb.git/codebase.git - not quite what I had in mind.

  1. I can do it again from /home/dev/ to fix the location, but it will still be called codebase.git - if I just change the name, will I break it?
  2. And then how do I swap roles between it and the codebase directory so that later I can get completed code from kizunadb.git to /thepath/codebase (with clone or checkout - not sure which is the right command at that point)? I know git doesn't really have the concept of "the main one", but I have noticed references in tutorials to "original" - not sure how that plays in...
  3. And then, how do I clone the repo to /thepath/dev so I can do branches without losing my work in progress? (I know I could move the whole directory out of the way, clone the repo, and then overwrite the repo's files, but I suspect there is an easier way.)

I'm happy to just start over if I have done things in the wrong order.

Community
  • 1
  • 1
OsakaWebbie
  • 645
  • 1
  • 7
  • 21

1 Answers1

2

First, this would work better:

cd ~
git clone --bare /thepath/codebase kizunadb.git

Second, a bare repo is for contributor to push to.

But to initialize your bare repo properly with codebase content, I would rather follow the workflow describe in "“fetch --all” in a git bare repository doesn't synchronize local branches to the remote ones":

cd /thepath/codebase
git clone --mirror . ~/kizunadb.git
git push ~/kizunadb.git --mirror

It can be completed with a post-receive hook in order to cd to the second non-bare repo and pull from the bare repo: see more at "Is --bare option equal to core.bare config in Git?".
That supposes /thepath/codebase is a git repo.

/thepath/dev would be a simple clone of the bare repo kizunadb.git, for you to develop in.

git stash will allow you to make branch without losing your work in progress.
See "GIT: commit changes to old/safe branch while in new/dirty/dev branch without checking out or losing unstaged data".

As you mention in the comments, for a single developer, a bare repo might be superfluous.
You could:

  • have only one repo: /thepath/dev
  • use a "git --git-dir=/thepath/dev/.git --work-tree=/thepath/codebase checkout -f" whenever you want to deploy code.

In that case, /thepath/codebase wouldn't even be a git repo, but simply a tree considered as a working directory for /thepath/dev on deployment.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. I recreated the bare repo your way. I still have the /thepath/codebase repo I made before, but it's independent of the other one now - is that okay? If so, what would be the command to get the code from the bare master to the production area after new tested code is merged in? For now I'll hold off on making an automatic post-receive hook (that sounds a little scary) - I'd add that after I get a better feel for what is going on by doing it manually. (And `git stash` looks perfect for my 3rd question - I'll study that.) – OsakaWebbie Apr 05 '13 at 06:36
  • 1
    @OsakaWebbie sorry, I forgot the initialization of the bare repo. I have edited the answer to reflect that step. – VonC Apr 05 '13 at 07:15
  • Hmm, as I read up on `--mirror` I got to wondering why I got the idea that I need a bare repo at all - perhaps I don't. I'm a lone developer of a project that is only deployed in one place. Everything I'm reading says that bare repos are for sharing, which I'm not doing. All this mirroring/pushing/pulling...for what?, I now ask myself. Maybe I just need to utilize branches carefully (on dev) and deploy to the production codebase when the `master` branch gets merged and looks good on a final test. – OsakaWebbie Apr 05 '13 at 09:13
  • 1
    @OsakaWebbie I agree. I have edited the answer to reflect that. – VonC Apr 05 '13 at 09:17
  • Sweet and simple - I love it! I have now been through the whole cycle to make sure it works. A few corrections on the deployment step, though, that I discovered through trial and literal error: (1) It's not `--git-work-tree` but `--work-tree`; (2) The --git-dir has to be `/thepath/dev/.git`, not `/thepath/dev` ("fatal: Not a git repository: '/myrealpath/dev'"); (3) the current directory must be `/thepath/codebase` when the command is run ("fatal: This operation must be run in a work tree"). – OsakaWebbie Apr 05 '13 at 15:02
  • @OsakaWebbie sorry for those typos. I have fixed them in the answer; Note that if `--git-dir` and `--work-tree` are there, you *should* be able to execute the checkout from anywhere. – VonC Apr 05 '13 at 15:04
  • That's what I assumed also, but run from the parent directory (`/thepath/`) with both paths absolute, I got: "fatal: This operation must be run in a work tree". Anyway, it works great, and WAY simpler than the initial workflow ideas I had. – OsakaWebbie Apr 05 '13 at 15:15