I am trying to spend as much time as I can on GitHub nowadays (even I am the only person in team at work) to really feel how it is going to be like for a real world corporate application.
One question I am having is to controlling the version. Let's say we started a project. Then, team members created some branches and develop there. When we are ready for the production, we merged all of branches with master
branch. At the end, we go live with version 1.0
.
Now that version 1.0
is live and we have some issues filed for that version of that software. We would like to start developing for version 1.1
in order to fix those issues that we had introduced by rushing the project.
Now, the question is this:
How should we control the versioning here?
Should we create a new branch for v1.0
and keep the version 1.0
of the software there and develop on some branches (or not), merged them with master
, go live with version 1.1
?
Is there convention out there for those kind of situations?
Best Answer
I have found (and started to adopt) the following branch model:
(image from the article)
There are lots of great practices and strict rules described in that article, I highly recommend it.
Points of interest:
In your specific case, the steps would depend on how rushed was that version. If it's features that were left out, I would go back to the develop release and do the whole thing again. If it's bugs in the deployed version, I would branch off to a hotfix branch, fix the bugs, merge back and tag v1.1. If it's both, I would fix the bugs first, then add the features second as described.