What's your ideal branch architecture within g

问题:

We're a small team of developers and building a web application. We're currently having a live, testing and several development environments.

What branch architecture would you suggest, so ideally each developer can work on his feature(s), these can be tested and deployed without tangenting other developers/features?

Currently, each developer has its own development branch and rebases into the testing branch. As soon as a feature is approved, the developer rebases his changes into the master.

This works as long as the features are tested immediately. However, if one developer is working on the next feature while the feature before is still tested, we need to handle things manually.

Thanks for opinions.

回答1:

It has been a while that I follow this useful guidelines described by Vincent Driessen in his article A successful Git branching model.

You can take a look there and you will see how he describes the branches management and avoid rebases

回答2:

I assume you're working with a centralized bare repository where everybody is pushing their changes, and then you're pulling the latest testing branch into the test environment.

Why not use Git as an actual DVCS and simply pull features from each user into the testing environment as the testing of the previous feature is finished?

If Bill is developing FeatureX, and Ted is developing FeatureY, they could make their features available on branches called testing/feature-x and testing/feature-y respectively, and you could simply checkout bill:testing/feature-x in the testing environment.

Failing all that, using multiple testing/feature-name-here branches would solve your problem in a traditional centralized system. Just have your users push their testing/... branch to the central repo, pull them into the testing environment, remove the branch when it has been tested. You can always see a list of features waiting to be tested by examining all the branches prefixed with testing/. If a feature's testing fails, you have a centrally located branch specific to that feature where you can add new commits to fix the feature before it is retested.

What are you doing now if a feature fails testing, after rebasing the feature onto the only testing branch? What if somebody else has rebased their feature for testing onto the branch which now contains a broken feature?

回答3:

For a web application, you're (hopefully) deploying working code daily, so you'll probably find a single branch (master) to be adequate. Use continuous integration/deployment, write good tests, and design your features to be released in small doses instead of all at once.

回答4:

This slidedeck (created after the OP and answer) was very helpful when I was exploring options, essentially recommends each developer branches from a single develop branch, and then pushes back there and rebases regularly for latest changes (caveats included).