Git production/staging server workflow
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:
- do a
git initin production server (is this safe?)
clonethe repo from production to staging server
clonethe repo from the staging to their local machine
pushfiles to the staging server after finish changing
- when staging is ready,
pusheverything 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?
2 Solutions collect form web for “Git production/staging server workflow”
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/
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.