Suppose you're developing a software product that has periodic releases. What are the best practices with regard to branching and merging? Slicing off periodic release branches to the public (or whomever your customer is) and then continuing development on the trunk, or considering the trunk the stable version, tagging it as a release periodically, and doing your experimental work in branches. What do folks think is the trunk considered "gold" or considered a "sand box"?
Do you continue development in a branch or in the trunk?
version control
Related Topic
- Git – the difference between ‘git pull’ and ‘git fetch’
- Git – How to change the author and committer name and e-mail of multiple commits in Git
- Git – How to undo the most recent local commits in Git
- Git – How to delete a Git branch locally and remotely
- Git – How to rename a local Git branch
- Git – How to see the changes in a Git commit
- Node.js – Do I commit the package-lock.json file created by npm 5
Best Answer
I have tried both methods with a large commercial application.
The answer to which method is better is highly dependent on your exact situation, but I will write what my overall experience has shown so far.
The better method overall (in my experience): The trunk should be always stable.
Here are some guidelines and benefits of this method:
If you try to do the opposite and do all your development in the trunk you'll have the following issues:
You simply will not have the flexibility that you need if you try to keep a branch stable and the trunk as the development sandbox. The reason is that you can't pick and chose from the trunk what you want to put in that stable release. It would already be all mixed in together in the trunk.
The one case in particular that I would say to do all development in the trunk, is when you are starting a new project. There may be other cases too depending on your situation.
By the way distributed version control systems provide much more flexibility and I highly recommend switching to either hg or git.