应该在版本控制的主干或分支中完成新工作吗？

Question

Hi i am learning about version controlling , trunks and branches . i have read some articles and i am confused now

one of them says .

• Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.
• The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/1.0.

so here it says every major change is done in the trunk and when software is ready for release you should create a branch and do small bug fiixes theres

but another one says

• trunk is guaranteed to be stable at all times

so seems that this one says , do major changes in branches :/

and a third article says

• Trunk represents the next major version release .
• A branch represents a specific release version.

So i am confused here .

I have few questions

1 when should we create a branch  ?  
2 Are we giving the release form branch or trunk ?  
3 Are we doing major changes in branches or only doing minor modifications
4 Are we doing the testing in branch or trunk 

Please answer these because i have spent more than 2 days to get an understanding about these and still i have no idea . Thanks in advance :)

UPDATE

Project is a PHP project
we are doing a relase in every 2-3 weeks
we are using git 
Team size is 4
All are familiar with version control

Answer 1

What you have encountered is the many patterns for approaching version control. A model that works well for a few projects I've worked on is this one:

http://nvie.com/posts/a-successful-git-branching-model/

The summary is thus:

• master branch (Always production-ready to deploy at anytime)
• develop branch (Represents the next set of features to go into production via merging into master).
• Feature branches (You may have several of these, representing the feature oriented work of subteams. For example, you may have one for feature-oauth, feature-loginform, etc, all would be merged into develop once completed).
• Bugfix/Hotfix branches (These are branched off of master when a hotfix is necessary, and merged back into master/develop when the bug/hotfix is done).

The article will help go into details about all of the different types. The workflow is designed to give you purpose built branches that make a statement about why they exist, where they came from, and where they are destined, which helps facilitate easy branching, merging, and team communication.

Ideally, this would exist on a git server like github/bitbucket/gitlab that supports pull requests, so project leads/owners can accept the changes and review the team's workflow, etc.

However, the bottom line is that there is no 'answer' to this question, only recommendations. Branching strategies are team specific, and the recommendations such as this one are very broad (they should help in a variety of cases), but you should favor a workflow that makes sense for your team :)