CODEWITHSUNDEEP
gitrepository
beNerd
beNerd

Reputation: 3374

Test and Production server setup with git

I am new to GIT. I have one production url and another as development url to which i want to push the new code.

development: http://development.myrepo.something

production: http://production.myrep.something

Now i usually work from different computers. I need a setup in which i can actually push all my work to the development url from different computers and when i get satisfied, i push the same thing in production url.

WHAT I HAVE DONE SO FAR

  1. Copied exactly same files on both the URLS. At this point both the URL's give me same result in broswer.

  2. Executed git init in both the directories and made them git repos.

  3. In the local git bash, I cloned from the production URL at some directory.
  4. I then added a remote origin like this - git remote add production ......//server path here
  5. Now i pulled from this repo like this - git pull production and it resulted like "UP TO DATE" which is what i wanted. Now pulling from both the branches give me the same message which is perfect.

So at thie point i thought, i can now work on local and then push to the development repo and when satisfied i can push again to the production repo.

But it doesn't work as whenever i push, it shows me the error because the repos aren't bare.

So what do i do now?

I am thinking to follow the branching approach from this Link

But the problem is that i want to see/test the work on the server in the development branch. With the approach mentioned in the above link, i can only see after the merge has been performed.

Please shed some light and point me in the right direction.

Upvotes: 2

Views: 4497

Answers (1)

kirelagin
kirelagin

Reputation: 13626

Have a bare repository on your server as a storage for production code, and setup a second non-bare repository somewhere near it which will pull from the bare one for testing. Dont' try to work against git.

The idea is that if you are using a repository to actually write code in it, then you shouldn't push to it.

So, first you create a repo for your code:

$ cd /path/to/dir/with/dev/repo
$ git init --bare

This is the repo you'll use as a central storage of your dev code, this one will be visible from the outside via http or whatever. You configure it as “dev” (or “origin”) remote in your working repos.

So, again, the repo you just configure is a push/pull-only repo, you don't actually do work in it: you write code in its clones and then push your changes. Even if you happen to work on the same machine, just clone:

$ cd /path/to/work/dir
$ git clone /path/to/dir/with/dev/repo

and when done push your changes back.

The same applies to your “production” repo. You set up a bare repository for production code storage, and then if you want to test it or deploy on the server, you just clone it to a non-bare repo on the same server—now you've got a repo for testing.

If you want your code to be deployed automatically when you push to a repo, there are a number of tutorials explaining how to achieve this with hoos (here is one of them).

Upvotes: 4

Related Questions