Using GIT on a development server

1 Views

Were a small wordpress development team who currently build our projects on a development server using mamp and once a project is ready to be live we FTP the site files to the production server. Currently when a dev needs to work on a file he/she will pull it from the dev.development.com server and once finished reupload the file so the client can approve the changes before FTP’ing the file to the production server.

We’re experimenting with GIT and bitbucket solutions and are wondering how we can use these tools to have source control with our code. We’ve tried various things over the past couple of days and are having issues on how we can maintain a codebase on the development server and have developers work locally. The dev server is a networked one connected to all our macs and has the mysql database that we use to connect our WordPress sites to.

Read More

Has anybody have experience of this or know how we can have source control with our setup – we’re keen to modernise our approach but we like the idea of having our development server to work on.

Thanks in advance.

Edit – for the SO trolls here is the question: How to setup git when you have developers and a local development server that clients access?

Post Views: 1

Related posts

Leave a Reply

1 comment

  1. A typical release life-cycle with GIT might look something like this

    Development:

    • all developers work against a local copy of the GIT repository on their dev system. You would have them run the “pull” command regularly to ensure they’re working against the latest code: http://git-scm.com/docs/git-pull
    • when they complete a change they commit it back to the Bitbucket repository via the “push” command: http://git-scm.com/docs/git-push. Ideally they would specify a commit message so you have traceability as to what they’re changing.

    Promotion to test server

    Promotion to production

    • when you have a release candidate–a set of changes which the client has signed off on–you would then “tag” them in the repository. A tag basically says “the codebase is stable and ready to be released”: http://git-scm.com/docs/git-tag. N.B: you’ll want to ensure that you’re tagging the exact revision that was tested, so be sure to keep track of it. (Alternatively, you can be more strict about it and only ever deploy tagged versions to the test server, but without a separate system integration environment/step in the release process this doesn’t add much value.)
    • you would then deploy that specific tag to production, more or less in the same manner that you deployed to the test server above (overwriting prod with the contents of the tagged version in the repository)

    Here’s a good primer/reference on GIT that may be of use to you: http://rogerdudler.github.io/git-guide/

    Hope this helps! If anything is unclear just let me know and I’ll edit my answer.