在基于Web的开发环境中使用GIT源代码控制

Question

I am currently using GIT with source Tree to manage my source control for a php web system.

My Previous experience with GIT is with a none web based environment and there for I understand the use of branches and remotes etc.

But I am a little confused when it comes to setting this up for web development.

Scenario.

I have a live subdomain
live.mysite.com

I have a dev subdomain
dev.mysite.com

I create branches off the dev site for stories. staff checkout the story branches from the dev site, complete and commit. Each story is then checked out by a tester and tested, once completed the story is merged to the dev master and eventually dev is merged with live.

This is a very broad overview and my confusion comes with the domains. lets say i have 10 staff members. They will need to view there changes as they do them the same with any development. Using the above method wouldnt work because all staff members would be deploying to the dev site.

To get round this i have been creating a subdomain for each staff member.

rob.mysite.com

dave.mysite.com

Now the staff can each work on there own domain independently and push to different remotes when needed. ie

make changes on rob.mysite.com push rob to dev push dev to live etc

Although this sort of works i feel it is not correct.

It almost breaks the whole point of branches as all staff would be branching from there own repository.

Is this correct and am I just a few steps short or am I completely off?

Answer 1

First of all, it sounds like staff members need a local development environment. Developers should not need to push any changes to test them. This slows down development a lot.

A common workflow could look like this:

1. Select stories to work on.
2. Develop your feature.
   1. Optionally, create a branch for it, which is based on the master or development branch. The so called feature branch. Technically, if a developer commits locally, this already is a branch.
   2. Optionally, push changes to a remote copy of the feature branch whenever you like to have a backup of your work.
3. Check if your changes work in a local development environment and run the tests.
4. If tests are green merge the feature branch into master/development branch.
5. Deploy master/development to the staging environment and have testers test it.
6. If tests are good merge master into live and deploy to live.

You might have noticed that this is not much different to your approach. You will have all changes in one single staging environment. However, this is a good thing. You will recognise incompatibilities between features there, not in live.

I would like to recommend learning more about Continuous Integration and Continuous Delivery .