Using Git as a source control for webdevelopment and multiple environment

Question

Little context: We are a team of 6 developers working a web application. Since launch we have been using CVS as our source control system on a Windows server using ColdFusion w/ Eclipse. With all the hype around Git and distributed systems lately we thought we would check it out.

As a standard web application we have our local environment where we develop new features/bug fixes. A development environment where we push everything for initial testing by QA. Staging where we send features/fixes that have been tested already this environment is to mimic as much as possible our production servers. Finally everything goes on the live system out in the wilderness...

This process is fairly painful sometime as most of it is done with FTP and what not and often we encounter conflicts when committing since something is taking longer than usual to test or when a quick bug fix is required urgently.

I am a little confused as to how Git would work in this case, it's obviously not an uncommon scenario but most of what I've found didn't talk about it in details.

If I understand correctly local branches play a significant roles with Git, I clone the git repository first then branch out fix something and commit it back all locally?

Then I get to commit it back to the main repository under the trunk dealing with merges conflicts if there are any?

If my assumptions are correct then the main question is what happen with staging. Obviously some features/fix take longer to test, some are more urgent, etc. Would I be able to simply do something like a pull of certain features/branches onto staging for final sign-off and then do the same from the live server (pull as they are signed off)?

It's quite a lot to take in coming from a CVS background...any help would be greatly appreciated!

Answer 1

• Local branches are important because you can create as many as you want, and merge them quite easily.
• Tracking branches (actually local branch following a remote tracking one) are much more relevant in your case, as thee allow you to formally link a local branch to a remote one, for publication purpose (another great feature of DVCS: you can "publish" commits to one remote repo or another)

The idea is to define:

• bare repo for pushing purposes
  • a dev bare repo where all devs can push their current work, and/or pull works from their colleagues (sort of a local "central" repo, but many other workflows exists, like the one described in this ProGit book page)
  • a bare staging repo where a staging branch is pushed with the stuff to test/validate.
    The QA team can clone that repo in order to get a staging working directory where they can run and test the web site.
  • a bare repo in a server in the production environment.
    The prod manager can clone that, and then rsync/ftp it to the actual production servers which will manage the live web site.
    Note: you should not have any DVCS on the actual production server. You should only have what you need to run/monitor a production environment.

The basic workflow is based on pushing/pulling branches between those environments (repos):

• on the dev and staging repo, you can maintain several official public branches, a bit like the Git maintainer Julio C. Hamano does it with his 'public', 'maint', 'next', 'pu' branches.
• before pushing anything to staging, you can rebase your work first on top of the remote staging branch in order to solve locally any conflict and update your local dev work with any fix detected/made in the staging area.
• pushing from staging to prod should be trivial (no conflicts, since no modification is done on the prod repo side)
• you can define hooks on the staging repo and prod repo to only accept certain branches, and refuse any branch creation (as oppose to all the dev repos where you can define/push/pull as many branches as you need)