Home/ Questions/Q 8799219
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T00:16:03+00:00

Recently we have started exploring GIT with the target of enabling our developers to

  • 0

Recently we have started exploring GIT with the target of enabling our developers to work from any place and secondly to automate the overall deployment process.

We have a central test server where we host all apps/sites for testing and/or demo purpose and once the development and testing is finalized we move the application to their respective live servers.

Whatever i have set up with GIT, is as follows
1. Create a bare repo on test server
2. Get a local clone for each involved developer, Developers will push to remote(test server) dev branch
3. Someone will merger all changes from dev branch to master branch and push it to remote
4. The test server (bare repo) has a post-receive hook, which checks out the master branch to public_html folder (using GIT_WORKING_DIR and checkout -f).

As of now, everything works good and i am able to see merge on master branch on hosted pages (on test server, of course). Now my questions are …
1. Am I doing this right?
2. I guess the post-receive hook I have set, executes on push to dev branch as well. How to avoid this?
3. How I can ship these contents to my live server? As I have some projects with large code base, checking out everything on test server and then ship it to live doesn’t looks good enough.

I’ve heard of CI servers, but as much as I know they check out locally and upload everything to live using ‘rsync’ (don’t know if it just syncs changes or uploads everything) or such tools. I just want to avoid that everything part and keep an option open to rollback, if anything goes wrong. I am good with setting up git on live servers.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team
    1. Yes. You can see other considerations at “reset hard on git push“.
    2. You can test the name of the branch when receiving the commits.
      branch=$(git rev-parse --symbolic --abbrev-ref $refname)
      See also “Writing a git post-receive hook to deal with a specific branch“
    3. a rsync is usually recommended for live server (where git isn’t necessary): it will update only what has changed.
      If you have git on live server, then various approaches are described in “Git for Websites / post-receive / Separation of Test and Production Sites“

    Regarding deployment, as seen in “Deploy with rsync(or svn, git, cvs) and ignore inconsistent state during deployment?“, deploying (even everything) in a separate directory and symlink the prod instance to that directory is a nice way of avoiding inconsistencies during deployment, and to facilitate rollback (symlink back to the previous live directory) in case of trouble.

    • 0