Git: proper order of clone, pull and push

Question

Here is the situation:

PRODUCTION SERVER

• Website A (/home/a/www)
• Website B (/home/b/www)
• Website C (/home/c/www/)

DEVELOPMENT COMPUTERS

[currently empty as we are setting things up... ever developer has an own client machine where we will be editing the files]

WHAT I DID

On Production:

cd /home/a/www/
git init
add .
commit -m "Initial loading of files"


cd /home/b/www/
git init
add .
commit -m "Initial loading of files"


cd /home/c/www/
git init
add .
commit -m "Initial loading of files"

So now all projects are in separate git projects. Now the idea is to load them on every developer's computer, who can then edit it and upload when necessary. Say I want to edit project B:

cd ~/
git clone ssh://server/home/b/www/ website_b

The developer then edits the website, and is ready to upload the changes:

cd ~/website_b
git commit -a -m "I have made some changes"
git push

I thought this was the correct procedure, and that this would upload my changes to /home/b/www/ on the production server. However, I get a bunch of warnings and things get mixed up. I have the same problem as here: git: updating the current branch.

However, I am very new to git and have a hard time understanding the concepts and the workflow. Branches, trunks, master, origin, are all a bit unclear to me. I want to keep things simple for now and just get it working. We never work with more than 1 person at the same time on one project, and we do not need to create sub-projects (branches?). At least, for now. I just want git to work. I want to:

• Download the current projects from the production server
• Make changes
• Upload them

That's all. What is going wrong here, or what should I read / learn / practice to better understand this?

Answer 1

Your workflow is perfectly fine. Only thing is that, the repos on the server that you push to from the developer machines should ( well, not should *) be what are called bare repos.

So when you create the projects on the server, do:

git init --bare .

This will setup the repos as bare and you can safely push to them.

Now, if you want the files that are there in the repo to be served from the server, git clone from the central bare repo to the location where you will serve the files from, and have hooks (like a post-receive) in the bare repo to either git push or git pull from the repos which you will use to serve your website.

Look here for details on that flow: http://toroid.org/ams/git-website-howto

* - The repos that you push to can be normal repos that have working directories, that is, checked out files ( non bare repo doesn't have these, only the metadata and objects of the repo). But it is a good practise to have a bare repo for the repo that you are pushing to. Look here for more detailed explanation on why this is so: http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html

Answer 2

There are some possible problems I was able to spot right away, but there might be more:

a) The user connected though ssh doing the push requires file io permissions on at least the .git repository to push to the remote repository if accessed in this way.

b) After (successfully) pushing to a remote repository with a working directory attached, you will not have the new commit automatically checked out. The working directory will remain in the state it was before the remote push.

I strongly recommend you use something like gitosis (deprecated) or gitolite to setup your (central) development repositories. Then you can push to the live server from your dev server. Note though that you must explicitly checkout the new commits on the live server then (I believe git checkout HEAD should do this for you). You can automate the chechout using a post push hook. The other option is to have the live server run a git pull on the dev server, which I personally like more. It does not require the explicit checkout and it must be issued from the live server, which allows better access control.