Git production/staging server workflow

Question

Currently my website (production server) already have a lot of code in it. And now I want to start using Git for my projects and setup a staging server for my team. Can anybody give me any advise?

Here is the picture in my mind:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

My question is, how should I start?

Here are some steps in my mind:

1. do a git init in production server (is this safe?)
2. clone the repo from production to staging server
3. developers clone the repo from the staging to their local machine
4. push files to the staging server after finish changing
5. when staging is ready, push everything to the production

Does this work flow makes sense, or there are some better way to do it?

What if I only want to change one file?

Does origin/master has anything to do with it in this process?? Who is the origin? am I going to end up having multiple origins??

Also, when should a developer use branch in this case?

Alisonalissa

Answer 1

It's better to use master branch only for Production and development branch for Staging. Each developer should create local branch to add new features and then merge with development branch. If you're new to a git, try to use - http://github.com/nvie/gitflow There is also good picture describing git branching model - http://nvie.com/posts/a-successful-git-branching-model/

Presocratic

This is a better answer. I wasn't very familiar with the concept of Git branching. – Alisonalissa

@Presocratic Do you have a link to some resource explaining the develop branch -> push to staging system and master branch -> push to production server in more detail? The superb article A successful Git branching model does not mention that part even if it does mention very good concepts of branching and versioning. – Cytosine

Answer 2

Your suggestion looks ok, but I wouldn't let the developers push directly to the staging server. Instead, an integrator should carefully review branches and incorporate them into the main branch (or development branch if you use the git flow model as suggested by bUg.) * The same person would push to the staging server.

* Integrator: "A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use..."

---

1. do a git init in production server (is this safe?)

Yes it's safe, but you of course have to set very restrictive permissions on this repo. I would probably start off by curling the whole web site to a local disc, if I don't already have it.

2. clone the repo from production to staging server

You should probably have a "central" repo separate from both the production and the staging server. That one can be cloned and pushed as needed.

3. developers clone the repo from the staging to their local machine

4. push files to the staging server after finish changing

5. when staging is ready, push everything to the production

Replace "staging" with "central" and I think you're ok, but a bigger issue is how you'll work with branches and merging, as bUg points out.

Song

1: To make Git repo safe in production, make sure to add a .htaccess file with "Deny All" inside. – Alisonalissa

2: Felixyz's "Central" repo is referring to bare repo. Use the --bare command to create a bare repo. – Alisonalissa

@keyue 1: Even better, add RedirectMatch 404 /\.git to your production .htaccess to protect your .gitignore, .gitattributes and .git folder. – Alfeus