Git production/staging server workflow

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:

  • Initializing private repositories on production server
  • Javascript/CSS File locations for development branch vs production branch
  • Optimal workflow for Local / Staging / Production server stack + Git
  • How do I push different branches to different heroku apps?
  • How to handle a git workflow mixed with SFTP and remote changes at the same time?
  • Prestashop Test/Production Server Best Practices
  •         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?

  • show current GIT branch name in windows command prompt
  • No git commands (status, show origin) not working, OS X Lion
  • Git: Create repo as submodule
  • 'origin' does not appear to be a remote repository
  • Git: staging area workflow
  • Can git tell me if a merge will conflict without actually merging?
  • 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.

    Git Baby is a git and github fan, let's start git clone.