CODEWITHSUNDEEP
gitsvngithubversion-controlmerge
Kanishka Panamaldeniya
Kanishka Panamaldeniya

Reputation: 17576

New work should be done in trunk or branches in Version Control?

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

one of them says .

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

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

and a third article says

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

Upvotes: 0

Views: 210

Answers (1)

tmruss
tmruss

Reputation: 322

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 :)

Upvotes: 4

Related Questions